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- Abstract 


A data abstsaction intreduces 2 data type with a hidden representation. Specifications 
of data abstractions are required to allow the data to be described and used without reference to 
the underlying representation. There are two main approaches to specifying data Sbstincoe: 
the abstract model approach and the axiomatic approach. 


This thesis is concerned with the problems of formalizing and extending the abstract 
model approach. A formally defined language for writing abstract model specifications is 
presented. The correctness of an implementation with respect to an abstract model specification 
is defined, and a method for proving the correctness of implementations is proposed. 


Our formulation treats data abstractions with operations that can dynamically create 
new data objects, modify the properties of existing data objects, and raise exception conditions 
when presented with unusual input values. 
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1. Introduction 


Specifications play an important part in the programming process, especially in the 
design and construction of large programs. It is generally accepted that large programs should 
be designed as systems of loosely coupled independent modules, so that each module can be 
designed and understood without reference to the other modules. A precise specification of the 
behavior of a module decouples the programs that use a module from the programs that 
implement the module, since programs that use the module depend on the specification of the 
module rather than on the implementation. The hope is that the specifications of a module will 
usually be simpler and more stable than the implementation of the module, so that the use of 
the specifications will make it easier to design, implement, and maintain the modules that make 
up a program. Specifications are also needed for program verification. 

The research reported here is primarily concerned with specifications for data 
abstractions. A data abstraction consists of a set of data objects and a set of primitive 
operations on those objects. The objects of a data abstraction are treated as abstract indivisible 
entities which do not have any directly accessible substructure. The objects of a data 
abstraction can be manipulated only by means of the primitive operations provided by the data 
abstraction.! The behavior of a data abstraction is completely characterized by the behavior of 
its primitive operations, and the observable properties of the abstraction are precisely those 


computable in terms of the primitive operations. Since the behavior of a data abstraction is 


I. The only exception to this rule is the boolean abstraction. The host programming language 
may provide statements, such as the conditional, which make the flow of control depend directly 
on a boolean value. These statements are not primitive operations of the boolean abstraction, 
and they cannot be defined using only the primitive operations. 
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independent of the way in which the associated data objects are represented in any particular 
implementation, introducing data abstractions is one way of decomposing a geasrane into 
independent modes (99, 40, 19, 4, 29). ‘The concept of representation independence is made 
more precise by the definition of behavioral equivalence of data models developed in Chapter 3, 
and it is the basis for the asual data type induction rule {53} | 

To specify the behavior of a data abstraction, it is sufficient to specify the behavior.of 
each operation, since the only way to interact with the objects of a data abstraction is by means. 
of the primitive senna The problem of specifying the Operations of a data abstraction 
differs from the problem of specifying procedures because ‘the specification of a data. abstraction 
must be iodependcia of the way the associated data objects are represented in any particular 
implementation of the abstraction. There are two main approaches to specifying data 
abstractions, the abstract model approach and the axiomatic approach. 

In the abstract model approach, an abstract representation for the data objects is 5 
defined, and the operations are specified in terms of the abstract representation. The ; 
representation is abstract because it is constructed from mathematically defined domains, rather 
than the built in data types of some programming language. The abstract. representation 
should be chosen so that the operations aan be defined as simply as possible. The 
representation used in the implementation of a data abstraction must often be chosen to 
optimize space or time efficiency, and may be quite different from the abstract representation. 
To prove the — of an implementation with respect to ‘a abstract model specification, it 
is necessary to define the correspondence between the representation used in the implementation 
and the abstract representation. | 


In the axiomatic approach, the set of data objects is defined implicitly, by giving a set 
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of axioms relating the primitive operations. The axioms specify the relationships that must 
hold between the operations of a data abstraction, and any structure satisfying the axioms is 
taken to be an acceptable model for the abstraction. If the axioms are consistent, then there will 
be at least one structure satisfying the axioms. It is possible for many different structures to 
satisfy the same set of axioms. To establish the correctness of an implementation with respect to 
an axiomatic specification, it is necessary to show that the operations of the implementation 
satisfy the axioms. An excellent treatment of correctness proofs based on axiomatic 
specifications can be found in [37]. 

The work reported here is concerned mainly with formalizing and extending the 
abstract model specification technique. We present a formally defined language for writing 
abstract model specifications. A criterion for judging the correctness of an implementation of a 
data abstraction with respect to an abstract model specification is developed, along with a 
method for proving that particular implementations are correct with respect to specifications in 
our specification language. Both the specification language and the proof technique apply to 
situations where mutable data can be shared. Previous work on specifications has largely 
avoided the issues associated with shared mutable data. Our formulation provides an 
integrated treatment of data abstractions with operations that can dynamically create new data 
objects, modify existing data objects, or raise exception conditions when presented with unusual 


input values. 


are 


1.1 Previous: Work i 


| Most high fvel programming languages havea eof bul in dat abutactions. 
| Languages that support user defined data abstractiqns have, been developed,. including 
. SIMULA 67 [5], CLU (20, and ALPHARD (54). . In. these Jangwages aprogram using a data 
| abstraction does not have to mention the representation of . that. abstraction, so that. the 
niaanen lati sibiine can be changed without. affecting. any ofthe applications programs 
ing the abstraction. | | 
: Surveys of specification techniques for data. abstractions can.be found. in (31) and in 
bes) | 
| The abstract model approach is direct in the sense that the set of data objects 
associated with a data abstraction is explicitly constructed. References to early. work-on abstract 
‘model specifications ss be found in (311 The problem of proving: the. correctness of ‘an 
implementation of a data abstraction with respect to an abstract model specification has been 
treated by Hoare in [18], and the problem. of proving. the correctness of programs using the 
objec and operations of a data abstraction has been treated by Shaw. in [47] In dotlr-cases, 
the specification language has been introduced informally, and shared data. has been excluded. 
The problem of specifying the behavior of data shared by concurrent processes has been treated 
in the context of the actor formalism by Yonezawa in [55] 
The abstract model approach is related to the denotational definition method for 
programming languages developed at Oxford by Scott and Strachey [49, 46], in which a 
mathematical model is defined for each of the constructs of a programming language, including 


the data domains. The major emphasis of the work at Oxford has been directed at issues other 
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than data abstractions. A formal treatment of a language with the potential for sharing 
mutable data can be found in [50], although the model makes little attempt to abstract from the 
storage representation of the data, A denotational definition of CLU, a language with facilities 
for constructing user defined data abstractions, can be found in [45]. 

The axiomatic approach is indirect in the sense that the set of data objects associated 
with a data abstraction is defined implicitly. There are several different axiomatic specification 
techniques, which are distinguished by the kind of logic in which the axioms are embedded. 

Axiomatizations of data abstractions in ‘i order logic can be found in [19]. A first 
order logical approach has also been used in the iota system [37] for constructing and verifying 
programs that use data abstractions. 

A restricted form of axiomatic specification using only conditionals and equations has 
come to be known as the algebraic approach (56, 10, 7, 13,9). The name stems from a uniform 
method for constructing a canonical model for axiomatizations expressed in this form. The 
canonical model is a many sorted algebra which is unique up to isomorphism, and which is 
called the initial algebra. A system for verifying programs using data abstractions specified by 
algebraic specifications has been developed at ISI (35, II, 36). | 

The problem of proving properties of programs that manipulate potentially shared 
mutable list structures has been treated by Burstall in [2]. Burstall follows a hybrid approach, 
by explicitly introducing a model and defining its behavior axiomatically. Proofs about 
programs that manipulate pointers have been treated by Suzuki and Luckham [5l, 32]. 

An approach to defining programming languages combining aspects of the direct and 
indirect approaches is being developed by Schaffert {44} Schaffert treats shared mutable data 


abstractly, and considers the problem of proving properties of programs using mutable data 


abstractions. 
1.2 Motiviations for this Work 


The original aim of this saaian cleuiean oc on emai a 
Behavior intended by the designer. We' started with the algebraic speciation ehnique, as 
described by the work of Zilles [56] and Guittag or “ 

After some preliminary investigation, it became clear that there were a number of 
phenomena associated with the data ‘types actually used be programmers that ‘cool not ot be 
adequately described by this ein technique as it stood, notably the dynam creation of 
data Objects, changes of state of potentially shared data, and exception handling. 

It also ippeared’ to be difficuke to cree a well formed a siebra spetiation for a 
new data abstraction, especially if the exact behavior required was not yet completely designed 
In our experience, a typical attempt to design a data abstraction using axtomatic specifications 
runs as follows. ‘After analyzing ‘the problem, ‘the operation of the data abstraction are 
determined, and the inputs and outputs of each ‘operation are e identified. ‘When the intended 
behavior of éach operation on a typical set of input values i is ‘fairly ‘well lindersioad, a 
preliminary ‘axtomatization is constructed. The ‘process of producing the "preliminary 
axiomatization helps to pinpoint special cases and boundary values for the inpuk domain, and 
the problem is analyzed further to determine appropriate behavior for the operation on unusual 
or ill formed input values. The axioms are examined in'light of the new design decisions and | 
are adjusted to conform. After a few iterations each of the axioms fooks plausible when 


considered in isolation. At this point the axtomatization is examined for consistency and 
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completeness. often at the cost of considerable effort. Fairly often we have found such an 
axiomatization to be inconsistent, and less often to be incomplete. It was disturbing to find that 
plausible axiomatizations could be ill formed, and that the effort of producing a precise 
description of a seeming simple design decision could be quite large. 

We also designed some data abstractions using abstract model specifications, and 
found that the process was much easier. One point was that inconsistencies in the design would 
usually surface immediately, because it would not be possible to define some operation so that it 
satisfied all of the informal constraints, while the usual result of trying to axiomatize an 
inconsistent set of design decisions io inconsistent axiomatization, which was often difficult 
to recognize as inconsistent. Another point was that minor perturbations in the behavior of an 
Operation were easier to describe for an abstract model specification than for an axiomatic 
specification. As long as the meaning of the abstract representation is not changed, a 
modification in the definition of one operation cannot affect the other operations, since in an 
abstract model each operation is defined in terms of its effect on the abstract representation. In 
an axiomatic specification the meanings of the operations are defined in terms of the relations 
between them, so that a change in an axiom can affect many operations. 

While the above is a very subjective judgment, based on our personal experience with 
a fairly small set of examples, we found that other people trying to use axiomatic specifications 
in the design process had similar complaints. This motivated a more extensive investigation of 
abstract model specifications. 

We found that previous work on abstract model specifications was largely informal, 
and that abstract model specifications were used without saying what the specification language 


was or what the specifications meant. Since abstract model specifications appeared to have 
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advantages from the point of view of design, establistiirig a precise mathematical formulation of 
“the specification technique arose ax a natural subgéal “Ih'the process’of pursuing this goai, it 
became apparent that dynaniic creation of data objects" stife chaiigei. arid exception conditions 


could be readily incorporated: into the’ frariework. At that time: ‘existing work on ‘axiomatic 


mis 


“specifications did not ‘address these issves; Which Kept ‘up in the design of programs. 
As a fesult, the direction of this research ‘shifted to developing and extending the abstract 
model specification technique, and thé original problem’ was' set abide as a subject for future 


investigation tion: 
1.3 Assumptions and Restrictions 


It the interests of defining’ a problem that can be treated in depth in a reasonable 
amount of time, we have miad® sofite restrictions oh the scope of our investigation. These 


be . Wi 


restrictions are explicitly stated betow: A more detailed discus 


‘of the restrictions and the 
reasons for introducing them cai be'found in Appendix 
_ We have riot’ conisidéred cases where mutable data is shared by concurrent processes, 
purposes. We have assumed ‘that each operation is deterministic, so that every computation 
produces a unique resuft. These assumptions lead to a simplet characterization of the 
observable béhiavior of a data abstraction thai would otherwise be possible. - 
We have adopted a model of exception handling in which ‘operations are terminated 
if they raise an exception condition. This restriction allows the behavior of an operation to be 
described independently of the behavior of exception handlers and ‘exception handling 


mechanisms, and teads to a clean model of data behavior. 
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We have assumed that each operation erent ny on the ae ah eg of the data 


objects passed to the operation as aE + Operations that depend on global data or on own 


data (ie. Spetalton® with internal sate) are 2 excluded pall this assumption Without such a 


4s ast fas 2 = 
Seenee ated feet? 


réstriction on the operations, plemet must bet treated | where the behavior of : a data ove may 
F - og GERD ge) ore 
be affected without applying an) of the primitive operations associated with the outa 


abstraction, and the concept of behavioral 1 equivalence (se Chapter 2) must be pehoemiititad: 


wei a a statboe : 


Since the behavior of such structures is not ‘counplesty characterized by the ‘havior sd ane 


primitive operations, we do not accept them as well formed data abstractions. 
1.4 Results of this Work 


We have investigated the structure of mathematical models of data » abstractions, 


developed a general framework for f proving the correctness of inpenenations and proposed a 


ity 


prototype specication language based on hee fenks. : 


oy 


1.4.1 Mathematical Models... 


A specification can be viewed as a method for singling out the structures (or models) 
that exhibit the desired behavior from those that do:.AOF, and the meaning: ef ‘@:specification can 


be identified with the class of models consistent with the saree This pies us a basis for 


judging whether or not two © specifications i in 1 two different formalisms have the same mveaning: 
The set of structures consistent with a given “axiomatic speciation ‘contains precisely. those 


structures in which all of the axioms are true. An abstract ‘wooded specication cenbies a 


Se 
particular model exhibiting the desired behavior a and the class of all models consistent t with the — 


ae 4 


specification contains Just those structures with the. same e externally observable behavior as the 


-- 
standard model. In this work, we have er! characterized el pe of he behavior of a 
data abstraction that are detectable by: an et observer. | 

_ We have described two 9 clase of algebra suucnes, , exception algebras and State 
machines, which ¢ can be used 2 as models fo data abstractions with exception conditions and | with 
state changes This work will be of interest t to to people wishing to extend the axiomatic technique | 
to include exceptions and State te changes wale it i explores th the kinds of structures that wilt mave | to 


be defined axlomaticaly. 
1.4.2 Proof Techniques 


In ve a fener of ‘Detayer ee Saga Semen: hecensioel of ‘dite: and 
exceptions, we. have found it necessary to reformulate hia ceria for ihe cel baauae of a 


proposed (ripest of a data abstraction, and to to deve new » chic for proving in 


correctness of an implementation with soma to the new criteria. These techniques are of 


interest also to people who wish to verify mutable iniplementitions “of date’ abstr ict 


respect to axiomatic specifications. 


1.4.3: Specification. Language 


3 


We nave ered a specication language for defining aaa ACTIONS. based on 


i 


ausiract models rhe Aanguage pa — ove a mathemati comeon¢ that is sufficiently 
toreia: to aegport eterna proms of f Masinee of the spritiation, and of the correctness 
of implementations We have made an effort to Incorporate hi of the eeatures necceahy for a 
practical specification lnguage. sates than to cine a Aanguage dengned to ofacitate provts of 


meta- -theorems about the gpscificatian sciictape We have intended this epee to serve asa 
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prototype, which can be used as a guide for people designing practical specification languages. 
The language presented here has been designed primarily to be read and written by humans, 
rather than to be mechanically processed (eg. by a program verification system). In some 
applications it may be desirable to use a more restricted language, in order to facilitate 


automatic theorem proving at the expense of making the specifications harder to construct. 
1.6 Overview of Remaining Chapters 


In Chapter 2 we explain the novel aspects of data behavior associated with exception 
conditions, dynamic allocation, and mutation of potentially shared data, and describe algebraic 
Structures suitable for modeling that behavior. 

In Chapter 3 we formally define the externally observable behavior of a data 
abstraction. The meaning of a data abstraction is associated with the class of all structures 
exhibiting the same externally observable behavior. The concept of a reduced model for a data 
abstraction is developed and explored. : 

In Chapter 4 we present a specification language for constructing models, along with a | 
mathematical definition for the semantics of the language. Each well formed expression of the 
language denotes an algebraic model. The construction of the model is explained, and the 
requirements an expression must satisfy in order to be a well formed specification are 
established. 

In Chapter 5 we state our basic definition of the correctness of an implementation, and 
develop a methodology for proving the correctness of an implementation with respect to a 


standard model for the data abstraction to be implemented. The methodology is illustrated by 


examples of correctness proofs. The basic definition depends on the material in Chapter 3, 
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while the examples use the language developed in Chapter 4. 


Chapter 6 contains our conclusions, a comparison of the abstract model specification 


technique to the algebraic technique, and indications of directions for future research. 
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2. Modeling Data Behavior __ 


We will define the behavior of a data abstraction by ceativeane a ‘standard model 
exhibiting that behavior. A model is a mathematical structure containing ‘cer pretaions for 
the objects and operations of the data abstraction. “The externally observable behavior of. a 
data abstraction consists of the results of all finite computations composed from the primitive 
operations of the data abstraction and yielding” obec of other types! An ‘abstract model is 
used to apeclly ‘the externally observable behavior of a data abstraction. All properties of a 


model that are not externally observable are irrelevant, in the sense » that they do not snflderice 


45 correct. with.sespett to: the 


standard model. We will say that two models are piaunia pleats if and only if they 


whether or not a proposed implementation of a deta_abstractior 
have the same externally observable behavior. “If two. structures. are behaviorally ee 
then’ they are models of the same data abstraction. “Behavioral a equivaene is treated in dept 
in Chapter 3." aa —* 

' ‘The standard model is intended to be a ‘isomorphic image of the data abitvadion as 
conceived by the designer: every object of ti the data abstraction imagined by the dexigner should 
correspond to a unique object in the standard model, and the (Goneosdenc should preserve 
the operations. The standard model of an abstraction can ‘be identified with the structure 


conceived by the designer, thus bridging the gap ‘betwen the inaccessible pattern in ae 


1. Except for the boolean abstraction, the only way to interact with the objects of a data 
abstraction is by means of the prirtitive operatiehs, so that the only way to export any 
-information from an abstract type is by means of the primitive operations yielding results of 
some other type. The interested. reader may wish to compare this idea with the treatment ‘of 
sufficient completeness in [10]. 


Das 
designer's head and a publicly accessible mathematical structure. A welf“designed standard 


model should be reduced: it should not be possible to delete an object from, the, model.or to. 


coalesce ti two ) distinet objets without affecting the externally, obseryabe, behavior of the.model. 
The concept of a reduced mode} is discussed further j in Chapter 3... 
| In this chapter we will conse: various aspects of the behavior of a data abstraction, 
and pase te en can be modeled using algebraic structures, but first, we have to, brtefly 
examine the internal structure of a data abstraction and the ways in which a set of data 


sbanaions can be related to each other. i 
2.1 Types and Subordinate Abstractions 


We will call a set of data one subject to the same operations a type. The definkion 
of a new data abstraction rode a new type, the Principal type of, the abstraction, Each 
operation of the abstraction involves bea of the principal type, and often also objects of 
other types, which we will call she quborainate types of the data abstraction. For exampke, the 
set re if sntegers is the c principal type of Shes imeger data a any, the set of booleans Js a 
sibordinate ‘ype. because the integer abstraction has the operations = and. < which map pairs of 
integers into ables —— type is the principal type of some unique data abstraction, known. 
as the defining abstraction of the ‘ip The primitive operations on the objects of a type are 
just the operations of its defining abstraction. | 

A model for a data abstraction must contain interpretations for the principal ore and 
operations, and also for the subordinate types, becauee the operations involve objet of the 
subordinate types as well as of the principal type. -Each of the-aubondinate types of a data 


abstraction d is the principal uf of its defining abstraction d’. Thus w we are usually dealing 
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with a set of related data abstractions, and with a set of related models for those abstractions. 
We will assume that systems of data abstractions are defined incrementally, where the definition 
of a model for a new data abstiaction explicitly introduces an interpretation for its principal 
type, and where the interpretations for the subordinate types are taken from the models for the 
defining abstractions for those types. This construction guarantees that a type is not given two 
different interpretations in a single system of models. However, a bit of caution is required, 
because it may not always be possible to define the data abstractions in a system in an order 
such that the defining abstractions of the subordinate types of each data abstraction are defined 
before the data abstraction itself. For example, suppose that the fixed point number abstraction 
has an operation for converting fixed point numbers to floating point, and that the floating 
point abstraction has an operation for converting floating point numbers to fixed point, say by 
rounding. In such a case, floating point numbers are a subordinate type for the fixed point 
number abstraction, and vice versa, so that it is not possible to define both types in an order 
such that their subordinate types have been previously defined. 

In order to make the idea of a hierarchically ordered set of type definitions more 
precise, we define the direct subordinate and subordinate relations as follows. 


Definition 1 Direct subordinate relation. 
If dy and 1) are data abstractions, then dj is a direct subordinate of do if and 


only if the principal type of d, is a subordinate type of a». 


Definition 2 Subordinate relation 
The subordinate relation is the transitive closure of the direct subordinate 
relation. 


We would like the subordinate relation to be a well founded partial order, but this need not 


always be the case, because two data abstractions can be subordinate to each other, as in the 
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above example. However, if we group eee ail of the data attractions th that are rma 
subordinate (ie, take the quotient with respect to the he largest eq equivalence relation » contained an 
subordinate), then the subordinate relation doe i in fact induce a pra onder on the roups 
(equivalence classes), — Se 

We will treat each group of mutually subordinate data sbaracions: asa single 
module. A model for such a module will have several principal types one for each data 
abstraction. Modules correspond to the ‘equivalence ass imroduced in ‘the previous 
paragraph. The subordinate relation for modutes is aiways a a partal ordering. This ordering 
is also well founded, because the set of data abstractions in any real system is finite Since the 
ordering is well founded, we can use * stroctural induction with rope to to the subordinate 
relation on modules when proving Properties of stems 0 of data \abarecions he e., to o establish sh a 
property for the data abstractions in the module m, we pa assume , the property hos for all 
abstractions subordinate to m). —— a 


It will usually be the case that each ‘module defines a single data abstraction, with a 


single principal type. In the following discussion we. e will often tacitly 3 assume e that each monet 
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has only a single principal type, ‘although the formal definitions will be formulated t to > deal with 


any number of principal types per model. 
2.2 Simple Abstractions 


The purpose of a standard model specification is:t0 provide an interpretation for:each 
type and for each operation of the data abstraction it iseaee A well chosen standard model 
should provide interpretations that are clean and simple. “The t most ‘yuitable modeling structures 


dépend on the kinds of behavior that must be dexribed. The simplest. case Is a data 
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abstraction without any exception conditions or any time dependent behavior, because in such a 
case the types can be interpreted as fixed sets of constant values, and the operations can be 
interpreted as functions on those sets. We will refer to this kind of abstraction as a simple data 
abstraction. The early work on algebraic specifications for data abstractions [56, 10, 7] dealt 
sanametiy with simple abstractions. Following their lead, we will model simple abstractions as 
heterogeneous algebras [1]. 
A heterogeneous algebra, also known as a many sorted algebra, is a pair (P, F), where 
P«{ P,|a@e€A} is an indexed set of phyla (also eins carriers), and where 
F={ Fg {8 B} is an indexed set of operations. The index sets A and B contain mo names 
of the types and fierations: respectively. Each phylum in P is a set of data objects. Each 
operation in F is a function Fg: Pag yy x. x Pa(B, n(B)) ~~ Pri6y where n:B-—>N, 
a:BxWN-—>A,and 1: B-> A are functions such that n(8) 2 0 is the number of arguments 
for Fg, a(B, k) is the type index for the k-th argument of Fg, and (6) is the type index for the 
return value of Fg, and where N is the set of all natural numbers. The principal and 
subordinate types of a constant data abstraction are interpreted as the phyla of the algebra, and 
the operations of the data abstraction are interpreted as the operations of the algebra. | 
Simple data abstractions are easy to describe, but they represent a very restricted class 
of abstractions, which almost never occur in practice. For example, the fixed point number 
abstraction, a common and relatively simple data abstraction, fails to qualify as a constant data 
abstraction on two counts. First, an attempt to divide by zero results in an exception condition. 
Second, fixed point numbers have a print operation, which modifies the state of an output 


Stream. Exception conditions and state changes are discussed in detail beiow. 
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2.8 Exception Conditions 


Many programming tanguages have data abstractions with. operations that may signal 
errors or raise exception conditions (we prefer the fatter term). A ‘common example is the integer , 
data abstraction, where an attempt to divide by zero’ résuks tia ‘exception. In gerieral, an 
operation should raise an exception whenever it is called with an argument omftside its natural 
domain of definition. -Siwations:tike this sre: quite-comment, so'that it is important to include 


exceptions. in our model of data abstractions. — 
2.3.1 Termination vs. Resumption 


_An exception causes a departure from the normal flow of control, to execute a program 
fragment intended to: santlle the’ exceptional ‘condition. ‘Iti Cased where the éXception handler” 
can recover from the exception, the computation may continue, and othetwise it must: be 
; aborted. There is no universally accepted modet for this process. - 

One viewpoint, which we shall adopt, is that an operation may have a number of | 
return points, one for the normat case, and one foreach exception. We shall refer to this 
viewpoint as the termination model of exception handling. According to the termination model, 
raising an exception is jus a special way of terminating an operation. 

An alternative viewpoint, which is cominonty’ held, is‘ that an‘ exception causes the | 
exception handler to be invoked as a procedure, with the tmptication that the operation that 
raised the exception will continue after the handler returns. We will refer to this viewpoint as 
the resumption model of exception handling. 


Both alternatives have been implemented. For example, in CLU an exception 
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conditions ee terminates the operation that raised it, while in PL/I the operation is resumed 
(for one class of exception conditions). A detailed analysis and comparison of the termination 
and resumption models can be found in [30], where it is argued that the termination mode! has 


a much simpler behavior than the resumption model. 
2.3.2 Termination Conditions 


We will assume that an operation of a data abstraction may terminate in any of a 
number of termination conditions [cf. 43], one of which (the normal condition) corresponds to 
the normal behavior of the operation, while the ainers correspond to the exception conduits 
that may be raised by the operation. The effects of an operation and the number and types of 
return values will usually depend on the termination condition. For motivational purposes, we 
will assume that when an exception occurs, the data objects produced by the operation, if any, 
are passed to the appropriate exception handler as arguments. 

A specification for a data abstraction with exceptions must therefore specify when each 
exception occurs, and what the results of the operation are for each termination condition. The 
definition of the host language must specify which error handler is associated with each 
occurrence of an exception, and what happens after the handler terminates. The only constraint 


we impose on the host language is that whenever an operation raises an exception, the 


operation is terminated before the handler is invoked, arid may not be restarted. 


2. This corresponds closely to the exception mechanism in CLU. In other languages, more 
roundabout methods may have to be used for passing information to an exception handler, 
such as assigning values to global variables. 
3. This constraint is implicit in [10] and [8)}. 


2.3.3 Exception Algebras 


In order to get a class of acer faloyee for mrecenne data abstractions with 


exceptions, we have to extend the notion, hal a $ algebra. In a heterogeneous 


eee SUR eA 


algebra as described in : {H, each operation is a function whose range is some eee of the 
algebra, but a typical operation of a data abstraction thay. returns thote than one ‘data “object, ‘and 
it ay return objects of ekien types i in } differen termination. conditions, _ Rather than 
Introducing phyla with a ai haga substructure, we prefer to relax the constraint on the 
allowable anes: of the x piscine: since we youn ike to D maintain a simple correspondence 
between the sypes of a data abstraction and fis phyla om he Foenscierl F Sree, nan 
exception aigebra, the reeks of a a typlal Operation s ved disjoint a of a family of sets, each. 
of which is a cartesian sence a some number of phyla (possiiy 2 zero! 

| We will also include the index sets rane we fmatet desing 0 the types ¢ of the 


pian as explicit a oil of ne e exception algebra, to n prevent contusion | in situations 


where we are dealing with several algebras in ee same e context. 


agate 


Befinition 3. Exception atgebra — ; 
An exception algebra is a tuple ( eg P, operations : F, _arglength n, argtype : a, 
ee aig Se m, type’: 7, typenamnes:: 4, TB, te gt D>), where 


as oh 


SS ‘set of Bape such that’ “each ‘Operation: ‘in F is a function 
Fp: PaiB.1) * ~ * PaiB, n(B) —” UA Re 17 6 18) 1, where, U denotes the disjoint. 
union operation, and where Ry = Pig 4 1) XX PHB 7 wiB,7)y 1: BN, 
a:BxN->A,(:B—>PAT) m:BxT N71: BxT xW-> A are functions — 
such that n(8) is the number of arguments for F B: 4B, k) is the type index for the © 
k-th argument of Fg, (8) is the set of all termination. copditions.that.may.resuk from 


4. The empty cartesian product is a singleton set containing the empty sequence. 
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F 6: m(8, T) is the number of objects returned by F “p.in the termination condition T,. 
and r(6, 7, k) is the type index for the k-th return value of F 6 in the termination 


condition T. A is the set of type names, B-is the set.of operation names, T is the set © 
of termination condition names, and D ¢ A contains the names of the distinguished 
principal types. N is the set of natural numbers. 


The details of this formal definition of an aca ans sili be wie primarily in Chaise 
3, and in the proofs of. the theorems. in Appendix. HI, The: following example may -help to 
clarify the meaning of the Various components: ofan; exception algetora: -LetA-be.an exception 
algebra model for the integer data abstraction. .Then-wehave: 


A.typenames = { “int”, “boolean” } 
A.opnames = { “plus”, “times’,."difference”, “quotient”, ... }: 


A. tcnames = { “normal”, "zero_divide” } 
A. pt ={ "int" J. ie 

A. phylains = {0, 1 4,2, -2,.. a 

A- phylayootean ~ {TF} 


A. operations yius ={Gywodlzexey } 


Quotes have been used to emphasize that the first four sets contains names (strings) rather than 
the sets they denote. Note that an algebra is a labeled tuple, and that we are using a dot 
notation similar to that used for the components of records in PASCAL to refer to the 
components of the tuple. If A.arglength = n, A-argtype = a, A.tc = ¢, Aeriength = m, and 
A. rtype = 7, then: 

n(quotient) = 2, 

a(quotient, 1) = a(guotient, 2) = “int”, 

t{quotient) = { normal, zero_divide }, 

m(quotient, normal) = I, 


m(quotient, zero_divide) = 0, and 
(quotient, normal, 1) = “int”. 


_ B- 
In the specification language described in Chapter 4, we will describe the type information for 


shies FE 
wht 


an operation in a compact syntax Hlustrated below for the quotient operation. — 
quotient: int x int —> ( normal: int ) + ¢ rero_divide : » 


The range of an operation, which is a disjoint cecion $s: writen ‘as ‘the sum of the components 

“for each termination condition. ‘The component corresponding th’ the terrhiination ‘condition 7 is 
written as (7: Ry ), where the normat component nmy He abbreviated by dropping thie arigie 
brackets, the colon, and the condition name. 


The reader should note that termination condita ‘deta objects are’ treated in 


jai oferetty } oo. raimee 


different ways, and that the inputs to an operation are ‘tears edinary data objects witch 3 are 


never used to represent exceptions. In previous work on spectyng pares mS: sai 


exceptions, exceptions were modeled as distinguished exception objects, which “were ‘e either 
elements of extra phyla [10] or distinguished subsets of the ordinary phyla (8) We have 
followed {43) in introducing explicit named termination conditions, maintaining a distinction 
between termination conditions and data objects, since we feel that this approach provides a 


more coherent and disciplined view of the exceptions associated with a data abstraction. 
2.4 Time Dependent Behavior 


Many programming languages have data abstractions with data objects whose 
properties may be changed. Two common examples are records in PASCAL and arrays in 
extended LISP. Since data abstractions with time dependent properties are in fact widely used, 
it is important to develop a formalism suitable for specifying their bbe vine 


An operation is non-functional if it is possible to invoke the operation with the same 
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arguments at two different times and get two distinguishable results. A data abstraction 
exhibits time dependent behavior if it has at least one non-functional operation. Data 
abstractions with time dependent behavior will be modeled as state machines. A state machine 
is a special kind of exception algebra containing a distinguished phylum of system state 
functions. The progression of time in a computation is represented by the sequence of system 
states of the state machine” 

We distinguish two kinds of time dependent behavior. If an operation changes the 
properties of an existing data object, we will say that the operation mutates the data object. Ifa 
data abstraction has no operations that mutate any data objects, then the abstraction is 
immutable, and otherwise it is widens If every invocation of an operation. returns a data object 
that is distinguishable from alf data objects that have been computed Sev easly we Say that 
the operation creates a new data object. If a data abstraction has no operations that create new 
data objects, then the abstraction is static, and otherwise it is dynamic. It is possible for a 
dynamic data abstraction to be immutable, as illustrated by the unique id abstraction described 
in Chapter 4. 

Mutable data abstractions are usually dynamic, since the possibility of sharing data 
objects goes hand in hand with the need to create new data objects. A change in the state of a 
mutable data object is visible in all contexts in which the data object appears. If all of the 
contexts in which a given data object is used are not known, as is often the case in a program, 


then the data object cannot be mutated without risk of violating the assumptions made about 


5. We are relying on our assumption that a computation is a single sequential process. The 
history of a parallel computation has been described’ as a partially ordered set of local states in 
[55). 
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the data object in some of the other contexts 5 in n which it ht way jaa ae ax newly created cata 
object is cnown to occur only in the context f in which it was renee and can } therefore be 
mutated without risk of terfrng with other pars of the Libeidauee 

Data abstractions that are mutable ¢ or cus will be modeled de state machines, since 


they exhibit time ie devenaan Sieh vior: Data abavactions that are, saat static ane mae 


can be modeled as exeyeen aera aeithowt. oe states. The hie ot this section is 


SEP eciae 


contaraed with state aching inbdek 


2.4.1. Data OQbjeste vs.. Variables 


| ‘In the early work on abstract dat spe, abu daa obeas were teatro as 
immutable values, and all changes of of state were Meni with assignments of new i apa AC 
values to program variables, This point of view is now widely sai and is often taken for 
granted in work on speciation for data abstractions However, as scary are in Hoare's 
pioneering paper + (18), this approach is not “suited for dexcibieg scgtamtnis manipulate 
pointers, or more ea for ee mutable data anarection’s that oleate Sharing of 
mutable data objects . : | 
The distinction between the + assignment of new vaties to variables and m mnutalion of 
data becomes important in cases where mutable ble data | is shared (several variable denote the 
same data object). Consider the example | from LisP ‘ustrated in Figure i. _ Suppose that 
initially the value of the variable x is the list (3) and the value of the variable 9 is the list (4 5). 
The assignment (setq x 9) will change the value of x to be the list a 5) which is identically the 
same list fe the initiad — of 9. This assignment has rot snthienced:the properties of the lists 


(3) or (4 5), and therefore has not affected any other variables whose values happen to be the 
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Figure 1. Shared Mutable Lists 


x ---> | 3 fonil | 


Initial state 


0 ee oe ee oe we om we oe ee or ee oe oe ee Oe ee om 


Y ---> | 4 | Kan | saad | 5 | nil | 


After (setq x y) | 


After (rplaca x 7) | 


— oe eo oe ee ee om 0 owe ae om oe oe Oe am Ee om om oe 


same lists as the original values of x or y. If we now modify the list x by executing the 
operation (rplaca x 7), we will have changed the first element of the list x to be 7. Both x and 9 
continue to denote the same list (the original value of ), but the first element of this list has 
changed, so that the value of either x or y would print out as (7 5). Whenever a data object is 
modified, that change is visible in all variables that denote the data object, and in all other 
data objects that refer to (or “contain") the modified object. 

The classical approach of associating all changes with the variables does not work 


very well in cases where mutable data is shared. If we were to insist that list values be modeled 
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as immutable sequences, and that all changes be desea uy siaguing ‘ae gales te the 
variables, then we would have a situation: where x rplace operation could change the values of 
arbitrarily many variables, depending av tone the data sisi thated: By associating states, , with 
the data: eres nemene| rather tharr with im, Le assaed we can overcome this difficuky, since _ 
changes can: be localized in an see centered jattiotion: An example of a description of a 

“mutable data structure with shared subcomponents can be found in Section 2.4.4. 

The treatment of potentially shared mutable data has been one. of the major goals of 
this work: betas approach is most Conty marched to che oriented iangusaged such as CLU 
and LISP, -and our -work is more or fess applicable to languages with pointers and heap 

allocation, such as Euclid, Algol 68, and PL/I. We treat Operations as functions that take a 
system state and some data objects, and produce a new system state and some ‘data ‘objects. “The 
variables of meen host programming tahguage do not expiicitly enter into our treatment, and we 

“feave a discussion of the assignment of data objects to variables to the definition of the: host 
programming language. Our treatment is directly applicable to:the programming language 
CLU, in which the invocation of an operation or ptocédiire may change the properties’ of some 
data ieeceon is guaranteed not to disturb the assotiation-Betweew variables and data objects. 
For host programming languages where the invocation: of a procedure may alter the association 
between variables and data objects, as: in (impute) LISP; Euctd, Algol 68, and PL/I, a 
jriestandionte has to ‘be made between the operations of the tlenguage and the operations of 
the abstract model for each data abstraction. 

There are two ways of incorporating abstractions with operations that assign to their 
input parameters in our framework. One way is to consider the abstractions to be immutable, 


with operations that return vectors of values to be assigned to the output variables of the 
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procedure. Another way to model such operations is to consider the L-values [cf. 50] of the 
variables to be part-of the data object rather than the variable, and to treat the data. abstraction 
as mutable, _ , | ite, genta 
The | first approach is well suited in cases where there is no © sharing of mutable data. 
' Aliasing can in fact introduce sharing tein the. formal. parameters of a ‘calt-by-reference 
procedure, so that special care is required in cases ses where the : same variable is passed in more 
. than one argument position [173 
In order to describe data objects whosé properties are subject io change, we will 
introduce a system’ state function, which maps each data’ object into its properties in the current 
state. Only the permanent properties of a data object’ are represented by the interpretation of a 
data object iw a state machine model, while the properties of a data object that are subject to 
‘charige are represented by the image of the object under the’ system state function. For most 


mutable data abstractions, the only permanent property of data object is its identity. 


2.4.2 State Machines 


Mutable data abstractions are modeled as state machines, which are defined formally 


below. A state machine is an exception algebra with a distinguished phylum of system states. 


Definition 4 State, Machine 
A state machine is a tuple ¢ phyla : P, operations : F, statefunctions : E, states: A, 
arglength : n, argtype: a, tc:¢, rlength: m,. rtype: 7, typenames : A, opnames : B, 
tcenames : T, statenames : S, ss: 5, pt: )), where P = {Py Ja € A} is an indexed set 
of phyla, and where F = -{Fgl8 © B} is an indexed set of operations, such that 
each operation in F is a function 
Fg: P,—( Pag ty x * Pa(B, n(B)y > Ps x UE Re tT © 8) }), 
where UU denotes the disjoint union operation, and where 
Ry = Px6, TA) %-X Py, 1, m(B, T)y z ={ La lac S} and 
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A={ A, tac S} are indexed sets such that each Ca c E, isa state function 

De Py > Mg OCP, then: & L4G hese: fori: tomeq ey © Bye! 
n:B—>Wa:BxXN—A,t:B—>RAT) me: BxT Wr: BxTxN Aare 
functions such that mB) is the number of arguments for dt for any system seine 


termination ‘Eonditions that may rile roe Fo), ‘wi. 7) is the pee of data 
objects veturned: by Fp(o) tn: the: termination condstion: 7, atid 48; 7,2) is the type 
index for the k-th return vatue of Fg{o) in in the termination condition 7 T. A: is the set Bia 
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of type names, B is the set of operation names, F is the set of termination condition 
names, D ¢ A contains the names of the principal types, 5 G4 captains the. by: 
the types that have a corresponding set of state functions, and s ¢ (A - S - DY ts the 


distinguished phylum of system States, W,is.the set of natural puspbers, 

The phylum of system states P, contains all possible. system, state, {unctions, one of which 
vurat the current global state. A. system. state er disjoint ynion of all. the 
ead ware “6 i aapeiven ioe fo-uialts 1}, where 
fridy—> ry is a function. f:Uld LEC RI? YU Ly Les By such that whenever 
xc Ufd, lic IE} and x= (i), fix) = Sf). Informally, the elements of the domain of the 
system state function are tagged with the name of the phylum they ¢ came ied so "that the same 
set can be used to represent many different phyla without causing any, interference, among the 
various components of the system state function. The. sets 2 4q and De. are fhe domains and 
ranges of the individual state functions, and hence are used in the construction of the phylum 


of system states P,, but they are not themselves phyla of the state machine, Teflecting the fact 


that none of the operations of the staté machine fake individual state fanctions or individual 
data states as arguments. The set of statenames 5 specifies: which Lila on “mutable 
types. Individual state functions are: associated ar with. the mutable a of a data 


abstraction. 
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The operations of the state machine are curried® so that formally an operation of a 
state machine is viewed as a family of operations parameterized by the current system state. 
This structure is introduced because the system state is qualitatively different from the other 
arguments of a typical operation, and because this structure makes corresponding notations for 
state machines and exception algebras more uniform. The operations of any immutable 
subordinate types are extended to take the system state as an extra argument, and to return the 
unchanged system state as an additional return value (the first component of the tuple of return 
values). 

Each operation of a state machine takes the current system state as its first argument, 
and when supplied with the rest of its arguments the operation produces the new system state as 
its firs return value. The reason for making the global state an argument to each operation of 
a data abstraction, rather than just the state function of the principal type, is that the operation 
may depend on or modify the state of some subordinate type. A common example of this kind 
of behavior is the print operation of a data abstraction, which modifies an output stream, but 
which usually does not affect-the state of any data object belonging to the principal type. | 

If none of the principal types of a data abstraction has an associated phylum of state 
functions, then we will say that the abstraction introduces no mutability. An abstraction that 
introduces no mutability may still exhibit time dependent behavior, and hence require a state 
machine model, if it has some operations that depend on or modify the state of some 


subordinate type, or if it has some operations that take or return mutable data objects. 


6. The process of abstracting from a function with n arguments to a higher order function 
which takes one argument and returns a function of n-l arguments is named after Haskell B. 
Curry (3). 
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2.4.8 Mutation of Data Objects — 


__ Ina state machine, the properties of a data object may depend on, the cursent.systere 
state. Typically the objects of a mutable type are modeled. as tokens.,without amy attributes 
except for their identity. The purpose of the state function. is to associate the curreat:data state 
of each data object with that object, so that the Same object can have, different. properties in 
different states. The set of data states Ag fat.the. type a is the. range. of any individual: state 
pinciea o ¢ 2, for that type. The data state of a mutable object is roughly analogous te the 
representation of an immutable object. in.an exception. algebra..,In an exception. algebra model, 
the properties of a data objet are computed in terms pf some. representation structure. while:in 
a state machine model, the properties of a data object are computed. in terms. of the: 
representation and its images under the state fonction, 

A very simple example of a. _rnutable data. abstraction is the integer cell,. An. integer 
cell is a unit of memory that can store an integer. value... A. model for, integer cells can. be. 
constructed by using the natural numbers for Picneger colt. and the, integers for: Aimteger’ cee 
since the only observable property of a cell that is subject to change js the identity of the integer 
currently contained in the cell The system state function o maps every natural’ number: . 
representing a cell into the integer that is the current contents of that cell: There are. three 
operations on integer cells: create, fetch, and store, The create operation creates a new cell with a 
specified integer as its initial contents. (The creation of data objects is discussed in Section 
2.45.) The fetch Satria applies the state function to the-cell to get its current contents, and- 
the store operation pene» a new syaem state that differs froin the old one ony in mapping 


the updated cell into its new contents. A language for saci models is defined in Chapter 
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4, and a number of complete examples of models for mutable data abstractions can be found 


there. 
2.4.4 Sharing of Mutable Data 


From the point of view of this work, the existence of sharing relationships among 
immutable data objects is not externally observable, since we are concerned only with the results 
of a computation, and not with the time and space requirements for performing the 
computation. A specification of an immutable data abstraction can therefore be constructed 
without considering potential sharing relationships. Sharing relationships among mutable data 
objects are often externally observable, so that they must be described in a state machine model, 
at least to the extent that they influence the externally observable behavior of the abstraction. 

To reflect possible sharing relationships, the set of data states is allowed to overlap 
with the phyla of a state machine, so that the data state of an object x may be or may contain 
another object y that lies in the domain of the system state function, and therefore has a data 
State of its own. This kind of modeling structure is indicated whenever the object x has a 
potentially shared subcomponent y, such that the state of y is subject to change and such that 
the externally observable behavior of x depends on the state of y. 

In the general case, the behavior of a data object x may depend on an indefinitely 
large set of data states, which are reachable from x by repeatedly applying the current system 
state to x and to components of other data states already in the set. We will call this set the 
reachability closure of the object x. For data abstractions where there are no externally 
observable sharing relations, as in the integer cell example, the set of data states should be 


chosen to be disjoint from the domain of the system state function, so that all of the state 


iat 
information is reachable by means of a single application of the system state function. 
Mutable binary eiaphe are a classic example of a data abstraction where sharing. 
relationships are important. This abstraction has operations for creating the null graph, for 
Creating a composite graph with given left and right subgraphs, for extracting the left and 
"right subgraphs of a composite graph, for modifying the left and Tight Ebcraphs of a 
composite graph, and predicates for testing if a graph is empty and if two graphs are identical. 
One way to construct a state machine model for binary graphs is to take Poinary graph to be. 
the set of natural numbers N, and Apinary graph to be the disjoint union nufl U (N x N). The 
data state of a graph is either null, indicating that the graph Is enpry, or it is a 2 pale of feature 
numbers representing the left and right subgraphs. “An illustration. of a Laue state o 
containing a number of overlapping binary graphs is shown in Figure 2 “Note that the wrap 
represented by the number 4 is a subcomponent of the graphs land 2. and is therefore shared. 
Binary graphs can also contain cycles, as shown by graph 5, which is its own left Eigraphs 


gt a 


The mutation of shared data is a phenomenon that has been avoided in most existing 


work on specifications for data abstractions. As the example in Figure 2 Indicates, it is not 


difficult to describe shared mutable data once we dope a pont of view centered on data objec | 


Figure 2. Shared Binary Graphs 
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rather than on variables, Some of the issues involved ia teasoning about shared mutable data 


will be discussed: in Chapter 5... ike: 
2.4.5 Creation of Data Objects | 


The principal type of a data abstraction is a-fixed:set for both static and dynamic data 
abstractions. For a dynamic data abstraction,-the principat type is-the setof all data objects of 
the given type that can be created by cis ata aoopaigstaias ie-terms of the. primitive 
operations of the data abstraction. . 

_ The population of a.dynamic data abstraction-d. in a.system state 0 is the set of all 
objects of the principal. type of d that exist. in the state 0. The concept ef a population is 
meaningless for static. data abstractions. - Singe -we -find: it-cenvenient to work with total 
functions, we adopt the convention that the. data stale of any object.that: has*not: been created 
yet is the special object undefined, which is a-member-of every phylum:of the. state mactire. 
All operations of the state machine are implicitly. extended ta apply to this-extra-object by the 


following strictness requirement: 
Wi[1 SiS n& x, = undefined = /(x, ..,x,) = undefined ] 


for any operation f taking n arguments, for any 2 2.4 -We-also adopt the convention that 
o(undefined) = undefined for every system state-o ¢ 2: 
Definition 5 | Population of a data abstraction. 

The population:of the. data abstraction ¢ in the system state 0 is: defined | to be'the — 


set {x ¢ P| a(x) * undefined }. 


We will. assume that in the initial system state every mutable type has an empty 
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populagion, and that objects are added to the population as they are created. We will also 
assume that every data object must be computed (ie., returned as the valve’ of some operation) 
before it can be used as an argument toa eee eacmida: 

We would like any program we can write in terms of the pions operations of a 
data abstraction to be guaranteed to return onty data Objects with’ a welf defined state, and we 
will calla data abstraction secure if it has this property. 

Data abstractions with: sperations that explicitly destroy data objects can be modeled 
readily in our framework, by having the operation change the state of the data object it is to 
destroy back to the original value undefined, thus removing it from the current population. 
Data abstractions with operations that explicttly destroy data objects:cannot be secure, because a 
computation that creates:an object, destroys it,and then applies any’ further operation to it will 
produce undefined as a-value: The problem of deciding ‘when it ts Safe to- explicitly destroy a | 
given data object must thus be addressed “anew for eath progratii that ‘uses Objects of an 
insecure data abstraction. This is known as the dangling’ reference ‘problem, and it is generally 
acknowledged to be difficult. 

We will concern ourselves mostly with secure data abstractions. The population of a 
secure data abstraction grows saonotonicaliy and the reachability ‘nuke of any object in the 
population of a secure data abstraction will never contain the data object undefined. 

| Informally, we will say that a model is reduced if it does not contain any unriecessary 
data objects. (A more careful definition of a reduced model can be fous in Section 3.3.) The | 
standard model of a data abstraction shoukd be redeced; since this generally teads toa cleaner 
Specification. In the context of a state machine model, this means that an operation should 


extend the population only when it creates a "new" abstract object. An abstract object is "new" 
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if it is distinguishable from every object in the old population by means of some finite sequence 
of operations. In practice the required sequence of operations is often very easy to find, since 
many dynamic data abstractions provide an equal operation which can be used to test if two 
abstract objects are identical. 

A very simple example of a dynamic data abstraction is the unique id abstraction, 
which has only two operations, create and equal. The create operation creates new simile ids; a 
newly created unique id is unique because it is guaranteed to be distinct from all previously 
created unique ids. The only way to create a unique id is by means of the create operation. 
The equal operation is provided as a means of comparing unique ids, and it is guaranteed to. 
distinguish a newly created unique id from any previously existing unique id. Unique ids are 
immutable (so that they cannot be forged or tampered with - one application for unique ids is 
in implementing capability based data protection schemes). 

This example illustrates that there is a state change associated with the creation of a 
new data object, as reflected by the increased size of the population, even though the properties 
of all previously existing objects may be unchanged. Note that the create operation is not a 
function of its arguments unless the state is explicitly included as an argument to the operation, 
because it will return different unique ids in different states, and it will never return the same 
one twice. 

Another example of a dynamic data abstraction is the impure list abstraction (as found 
in LISP), with the operations cons, car, cdr, atom, equal, eq, rplaca, and rplacd. Each time it is 
called, the cons operation constructs a new list, which is distinguishable from any previously 

| existing list by means of the eg operation. The impure list abstraction is also mutable, because 


the rplaca and rplacd operations can be used to modify the contents of existing lists. These 
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operations can also be used to distinguish a new created is from a previously existing list 
with the same contents, by moditying one of the lists and looking to see if the other is changed 
also. If the lists are distinct, then one will be ange and the salves will not be. This the 
ical list ADsraCHON would be dynamic even i enout the q operation in the general case, 
two abstract objects are identical only if they have thes same ere propeniss in the. current 
state, and if ee are guarantee to have the same properties in ali subsequent states. 

Consider a restricted kind i list, which set ihe same Speretions as the impure lists of 
the previous example, except for eq, rplaca, and aie This list abstraction is aramnutapee, and 
also static, because there is no way to dining the list returned “tl one invocation of cons 
from that returned by a later invocation with the same arguments, ins example demonstrates 
that whether or not a given operation returns a new abstract data object depends on the other 
operations of ine abstraction. It may require a et of thought to decide if a given data 
abstraction is in fact arene, and rae bi ala a state ¢ machine model, or if it is static and 


immutable, and hence should be specified by an exception algebra model. 
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3. Denotations for Data Abstractions 


The nesting (or denotation) of a data abstraction is the class of all models of the data 
abstraction. In the axiomatic approach to specifying data abstractions, this class is taken to be 
the class of all models satisfying a given set of axioms. In the abstract model approach, the 
Class of all models of a data abstraction is taken to be the set of all models with the same 
observable behavior as a given model, which is explicitly constructed. 

In this work, we will assume that a model for a data abstraction is an exception 
algebra. We will say that a model is dynamic if it has a distinguished phylum of system states, 


and that it is static if it does not. 
3.1 Complete and Partial Models 


A model for a data abstraction d is complete if and only if d has interpretations for the 
types and operations of d and of every data abstraction subordinate to d. The externally 
observable behavior of d is characterized by the finite computations in terms of the operations 
of d and the abstractions subordinate to d, and any such computation can be interpreted in a 
complete model for d. A partial model for d may leave some of the abstractions subordinate 
to d uninterpreted. 

Since the identities of the objects in a model are not a priori observable, there may be 
no way to compare the results of a closed computation in two different models. This problem is 
resolved by insisting .on a unique standard model for the booleans, containing exactly two 
boolean values, so that the results of any computation producing a boolean value can be 


compared for any set of models. To reduce all comparisons of results to the problem of 
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comparing boolean values, it is necessary to jnckide the operations. of the Gneraidale 
absirection®: in nite pengurations Thus complete n models are Tequired | to make, sure that every 
computation of interest can be ierpreted 
. in practic, a system of Gate abstractions is eecibed incrementally, by giving a partial 
description for each abstraction or set of mutually subordinate abstractions) d in the system. 
The Sarit esectotions give a prescription for constructing interpretations for.the principal | 
type and operations of d, assuming that pcompt models for the abstractions subordinate to d 
are already defined. In Peru’, the phe! aerchiocen of the. subordinate types of d are to be. 
taken from the models for the setiaing abstractions of those types. The construction .of a . 
complete model for d is described more precisely below! | 

| Let d be a data abstraction, let qd), at d, be the abstactions subordinate to d, and 
let m; be a complete ne nes d; for each tin the range | Isicn. Suppose we have a partial 
; description D for d, which giver. the signature of d, the name of the principal type of d, and 
interpretations for the ‘rincigal eee and operations of d. If D describes an exception algebra, 
then a corphers nade! m for d is constructed as follows. 


m.ops = D. ops U ( oe mi; ops ) 
Sisn 
Me  argiength = D. arglength Li ( : ene ‘m; arglength } 
m. argtype, m. tc, m. rlength, ne me os are similarly defined as disjoint unions. 
m. typenames = D. pee. re Mio typentines) . 
m. opnames = D. opnames Wl a es + Ophiames ) 

m-tcnames = D.tcnamesU( Um, tcnames ) 

: vos ISiSn Si 


|. The details of this construction are not essential for an understanding of the rest of this 
work, and may be skipped on a first reading. 
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m. pt = D. pt 


where U denotes disjoint union and where U denotes ordinary set theoretic union. If D 


describes a state machine, then the above relations still apply, and we have to add the following: 


m. statefunctions = { D. statefunctions } U { m,. statefunctions | m, is a state machine } 
. D. pt ad mye ptt t 
m. states = { 1). states, pt }U { m;. States, pt | m; is a state machine } 


m. statenames = D. statenames U ( U { m,« Statenames | m, is a state machine }) 
m.ss=D.55 
me phyla, .={UlOglac S}lo,¢ Ly foreachac 5} 


where S = m. statenames and & = m. Stateftinctions. 


In the rest of this Chapter, we will limit our discussion to complete models, and we will 


frequently leave out the qualifier “complete”. 
3.2 Behavioral Equivalence 


Informally, two models are behaviorally equivalent if they have the same externally 
observable behavior. In this section we develop a precise mathematical definition of an 
equivalence relation that captures this informal notion. We define closed computations, and the 
interpretation of a closed computation in a model. Two models are behaviorally equivalent if 
they contain interpretations for the same types and operations, and if the value of any finite 
closed computation in one model is indistinguishable from the value of that computation in the 
other model. 

Behavioral equivalence is an important notion, because it is the basis for defining the 
correctness of an implementation of a data abstraction. An implementation defines a model for 


the abstraction it implements, and the implementation is correct if the model it defines is 
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behaviorally equivalent to the model that specifies the abstraction. 
We can Hailed Sat omen two models only if they have verprcratons for the 
same types and operations. Two modets an ) be behaviorally equivatent. only if they have the 


same signature. 


Definition 6 Signature 


The signature of an exception algebra @ is the tuple 
( arglength : a. arglength, argtype : a. argtype, | 
tc : a. tc, rlength : a. rlength, rtype: a. rtype, 


typenames : a. typenames, opnames : ¢. opnames, tchames.: €. tenames... 
If two Sreeption algebras have the same agnalure: then 9, have ne same names for the 
phyla, operations, and termination ‘conditions, and coreponding operations have the same 
numbers and types of arguments, the same set of possible termination ‘cobaitions and the same 
numbers and types of return values in each termination: doed#ion.::As a matter. df: notational 
convenience, we require comparable models to be indexed ay the same sets, so that 
corresponding wpe and operations have the same names, “and we can “talk about the 
interpretations of the same e operation name in several | different me models. | 


In order to characterize the kinds of behavior a data abstraction may exhibit, we 


define the set of closed computations. 


Definition 7. Closed computation 


A closed computation with respect to a signature S is a finite sequence of pairs € 
such that 

Cli) = Cop : f, args : 5 ) for each i in the range | Si S-length{C), 

where f ¢.S.opnames, and s is a sequence of argument mea ai such that 
length(s) = 5. arglenth(/),. 

s{j) = ( step: n, tc: T, result : k ), “(the source of the fth argument to f) 
ISn<i, - (nisthe index.of a previous step of the computation): 

T¢ S.tc(C[n].op), (7 is the required termination condition for step n) 
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1<k<S.rlength(C{n). op, 7), (the &-th object returned by step n must exist) 

and S.rtype(C{n)}. op, T, k) = S.argtype(f, j) (and it must have the right type) 

for each j in the range | < j $ length(s). 
A closed computation is a sequence of steps, where each step is the application of some 
operation of a data abstraction to data objects resulting from previous steps. Every 
computation starts from nothing, and computes data objects as it proceeds. A closed 
computation is analogous to an uninterpreted flowchart, since the sequence of the operations is 
given, but the operation names are left uninterpreted. A step is a pair consisting of an 
operation name and a sequence of argument: specifications. An argument specification is a 
triple, which specifies a previous step, a required termination condition for that step, and the 
index of the desired result. The index is necessary because an operation will in general return 
more than one object, and we have to say which of the returned objects to use. Since the 
number and types of objects resulting from an operation can be different for’ different 
termination conditions, an argument specification requires the step producing the argument 
object to terminate in a particular termination condition, so that we can be sure that the 
Specified data object is of the proper type. A closed computation can fail to have an 
interpretation in a given model, if the termination conditions actually computed do not match 
the required termination conditions in the argument specifications of the closed computation. 

An example of a closed computation Cl over the list abstraction of pure LISP is shown 

below. 
Cit] = Cop: nil, args: <)>) 


Ci[2] = Cop: cons , args: ( ¢ step: 1, tc: normal, result : 1), ¢ step : 1, tc: normal, result : I > 
1> 


»> 
CI[3] = ( op: cons , args : ¢ ( step : I, tc: normal, result : 1), ¢ step : 2, tc: normal, result: 1) >) 


This computation computes the value of the LISP expression “(cons nil (cons nil nil)”. 
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A closed computation consists of a finite sence of operations, with no conditionals 
or other contro! structures, and can be thought of as a trace of the execution of some preree 
that uses the operations of the data abstractions of interest. The finite prefixes of the history of 
any program can clearly be described by a set of closed ‘computations, and any finite closed 
computation cart be destribed by a program in just about any programming language. Note 
that a machine for executing closed computations requires an 1 unbounded amount of memory, 
because it is assumed that theiresutts of each step are saved, and may be used in any number of 
succeeding steps. : - 

We-want to know whether or not there is some computation that yields observably 
different-restits wher interpreted in each of the two models whose behavior we are comparing. 
It is sufficient for this: purpose to consider only thé finite computations: given two infinite 
sequences, if we know that their prefixes ef length n are the same for every natural number n, 
then the original infinite sequences must be the sare as well 

The interpretation of a computation in a given model is the sequence of resuks 
obtained by apptying the interpretations of the specified sequence of Operations in the model to 
the specified arguments. Since the interpretation of an secsoan is different for. static and 
dynamic models, we will give separate definitions for the interpretation of a closed computation 
in each kind of model. 

Definition 8 interpretation of a Computation in a Static Model 
Let M be an exception algebra model, let F = M. operations, let n = M.arglength, let 
C be a closed computation with respect to the signature of M, and let I be a 


sequence. I is the interpretation of the computation C itt the model M if and only if 
all of the serene conditions hold: 
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I. length(I) = length(C), 


2. For each i in the range I $ i < length(C), 
Tift} = Fels... .¥ (gy) where Cli) = (op : B, args: s ), 


3. For each j in the range 1 < 7 < n(B) 
x4 = obj(I{k}) {w], where s[j] = ( step : k, tc: 7, result : w ), and 


4. te(I[k)) = 7. 

A computation is a sequence of operation names and argument specifications, and the 
interpretation of a computation in a model is the sequence of values obtained by applying the 
interpretations of the specified operations in the model to data objects specified by the argument 
specifications. The set of operations of a model is indexed by a set of operation names, and the 
indexing function specifies the interpretation of each operation name in the model. Since an 
operation may return more than one data object, the interpretation of a computation is a 
sequence of tuples of data objects, injected into the component of the disjoint union 
corresponding to the termination condition produced by the operation. Recall that the range of 
each operation of an exception algebra is a disjoint union of a set indexed by termination 
. conditions. Each element of a disjoint union is a pair, containing a tag and a data object. If y 
is the result of some operation of an exception algebra, then obj{y) denotes the object without 
the tag, and te(y) denotes the tag, which is the name of a termination condition. 

The interpretation of the computation Cl (shown above) in the usual model of pure 
LISP is the following: 

Tl [1] = ¢ normal, ¢ nil > ) 


Ht (2) = ¢ normal, ¢ ( nil) >) 
It (3) = ¢ normal, ¢( nil nil) >) 


The pairs stemming from the disjoint union are shown explicitly. The first component of the 
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pair is the tag (saanstion condition), and the second eae is ‘the s sequence of data objects 
resulting from each operation. Since all of the joa siomshooe ia ths exarople reture’ a single 
value, the resulting data objects are contained in enero hace - 

Note that the termination condition of each step must match the ci condition 
required ‘by every argument specification that uses the results of that step. A ‘cia 
computation may. or may not have an interpretation ina rnoriel. ifan Interpretation exists, it is 
unique, becauise the operations of a exception algebra 3 are e functions, which necessarily iave 
unique values. A computation may fail to have an  ierpreation ina given model because the 
operation specified by some step of the computation may terminate ina . different condition than 
the one required by some later step that uses ‘the results of the give Hep. It several steps of a | 
computation make conflicting requirements on the termination condition of a given sep. then 
that computation will not have an interpretation in any ‘model of the abstraction. if a | 
computation has an interpretation in a model, we will say that the computation is feasible in 
that model. A feasible computation can involve steps with exceptionai termination conditions, 
and it is possible for the termination condition of the final step to be normal even if the 
termination conditions of s some intermediate steps a are exceptional | 

The interpretation of a closed computation ina ‘dynamic model ay similar, except that 
there is an extra component containing the system state Recall that the first argument and the 
first return value of every operation of a state machine is a system state. | 
Definition 9 ~—s Interpretation of a Computation in a Dynamic Model. | 

Let M be a state machine, let F = M. operations, let n = M.atgiength, let C be a 
closed computation with respect to the signature of M, and let I be a sequence. II is 


the interpretation of the computation C in the model M if and a if all of the 
following conditions hold: hi 


1. length(I) = length(C), 


2. For each i in the range 1 < i ¢ length(C), 
Ii) = F g(0;) Wey ans Xn (By) where 


Cli] = ( op : 6, args: s ), 
O;=Ax. undefined  ifi=1 
Oo, =objT-MMN  ifi>t 


3. For each j in the range I < j < n(6) 
xi obj(H[k})(w +1], where s[j] = ¢ step: k, tc: 7, result : w >, and 


4. te(H[k)) = 7. 
The initial state for any computation sequence is the empty state, which maps every data object 
into the initial data state undefined and thus has an empty population (ie.,no data objects 
have been created in the initial state). Each step of a computation except for the first step starts 
with the state produced by the previous step. The interpretation of a computation in a dynamic 
model is a sequence of tuples, whose first component is a system state, and whose remaining 
components are the tuples of data objects and the system states produced by the operations 
specified by the closed computation. Since the first return value of an operation of a state 
machine is always a system state, the w-th data object returned by an operation of the abstract 
type corresponds to the (wel)-st component of the sequence of values returned by the 
interpretation of the operation in the state machine. 

If a computation has an interpretation in a given model, then the value of the 

computation in that model is the result of the last step of the computation. 
Definition 10 Value of a computation 

If the computation C has the interpretation Il in the model M, then the value of C in 

M is obj(I[length(I)}) if M is a static model, and the value of C in M is 

¢ v[2], ..., ullength(v)] ) where v = obj(I{length(I)]) if M is a dynamic model. 


Note that the value of a computation can be a tuple containing more than one data object. The 
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final state of the interpretation of a computation in a state machine is not part of the value, 
since it is not directly externally observable. 
We are now ready to define behavioral equivalence. ., 

Definition 11 Behavioral Equivalence of Models . 
Two models Mi and Af2 are. , behayioraly. equivalent. if and only . if all of the 
following conditions hoid: 

1. Ml and M2 have the same signature S. 


2. For any finite closed computation C’ with respect to the signature S, C has an 
interpretation in Mi if and only if it has an interpretation in Me 


3. For any finite closed computation C with respect to the Signature $, C has an 
interpretation in Mt and the vatue of Cin MIB the Boolealt Vahie's if and only if 
C has an wag sbdpnrt in M2 and the value of C in ees is Las same. boolean . 
valuet. . 
Two models are behaviorafly equivalent if they have the same signature, interpretations for the 
same set of closed computations, and if every computation resufting In a Boolean value has the — 


same vatue in both modets. 


Theorem 1: Behavioral equivalence is an equivalence relation. 


Proof : The theorem follows digectly from the definition. 
End of Proof 


We intend two models to be behaviorally equivatent if and only if they have the same 
externally observable behavior. In practice, what’ we can really observe is the output of a ; 
program, which is usually manifested as characters printed on a piece of paper, or displayed on 
a terminal. Although there is a wide variety of peripheral devices thar can be connected to a 
computer, capable of producing a wide variety of obiervable effects, they can all be modeled by 


a (mutable) output stream data abstraction sufficiently ‘well for our purposes, since we are not 
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concerned with the actual physical properties of the output, but only with whether or not two 
outputs are distinguishable. We model the data states of an output stream as finite sequences of 
integers (which can be interpreted as character codes in most cases). We assume output streams 
have an operation that returns the current state of the stream, represented as an immutable 
sequence of integers. This operation models the system user, who observes and compares the 
actual outputs of the system, and it need not actually be implemented. It is included because 
some data abstractions have properties which can affect the printed output, but which cannot 
be tested by another program. 

Integer sequences are defined to be a priori distinguishable because they are used to 
mode! physically observable outputs of the system. Note that the states of mutable data 
abstractions other than output streams are not a priori observable. We will further assume that 
integer sequences have an equal operation which allows us to reduce the problem of comparing 
sequences of integers, representing states of output streams, to the much simpler problem of 
comparing truth values. 

The domain of truth values is a priori distinguishable because of our assumption that 
the host programming language provides some means of altering the flow of contro! depending 
on a truth value. For example, a conditional statement that prints a different message on each 
arm can be used to physically distinguish between the truth values. Because of this property of 
truth values, we insist that the boolean abstraction be given the standard interpretation in ali of 
the models that will enter our suainion. In the standard interpretation, there are exactly two 
truth values, T and F, with the operations and, or, not, implies, and equivalence (see Section 4.2.1 
and Appendix 1). 


Different termination conditions are also externally observable, because we can 
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associate handlers that om different t_ messages with sich exception. We do not have to 
introduce any extra machinery to treat this Case, because it i ae covered by co definition 
of the interpretation of a computation, i the final I sep of a computation ¢ Cc results in two 
different termination conditions in ‘two different models, then n by mag one more sep that uses 
the results of the fast step of C and that 1 requires it to terminate in one of the two observed 
termination conditions: we will get a closed computation C c’ that is s feasible in one model but not 
in the other. | | is 

In so definition of behavioral equivalence, we have een that all of the aspects of 
the behavior of a data abstraction can be cburved ‘by means of the operations 4 the 
abstraction and its sitbordisiaie abstractions If every operation of every abstraction in the 
system computes r results that depend only on the _ a ee explily aleieat aise as ere 
or on the data states in 1 the reschabalty doaare of the arguments ik Section 13, then this 
assumption is justified. An example of a ace that violates this assumption is the following. 
Suppose that the abstraction NASTY has an operation count that returns a natural amber 
representing the number of objects of type NASTY that have been created so far, and that the 
only operation that creates new objects of type NASTY i is the nullary create operation.. In order 
to implement this behavior, the creafe and count operations must share some own data. If some 
other abstraction A in the system is implemented _— a representation containing a object of 
type NASTY, then the operations of 4 ean have effects which are say observable by means of 
the count operation of NASTY, even though NASTY is a wiecessaiily subordinate to A (ie, 
A need not have any operations that operate on or return any objects of type NASTY). In 
general, abstractions with state components that are associated with the type as a sis sathce | 


than with any individual data object cannot be used to represent objects of other types without. 
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introducing hidden interactions of the a described above.. Becaste! we: Bailes the behavior of a 
data abstraction to be independent of the Eis steered used dn any. particular implementation, 
we exclude structures like NASTY from. our-discugsten..; The: specification latgtage presented 
in Chapter 4 has been designed so that abstractions violating this locality assumption cannot be 


defined. 
3.3 Reduced Models 


Data abstractions are identified with equivalence classes of models with respect to the 
behavioral equivalence relation. In this section we will skow how to construct a representative 
element of such an equivalence class, known as : rediied nod which an be used to — 
the behavior common to all of the members of the cass. “Reduced poser are shown to be 
unique up to isomorphism, and fies are e minimal in: the sense that they contain. no ummecessary 
elements. Models to be used as specifications for data. abstractions should be reduced, since 
irrelevant components serve no useful purpose and may lead to BD COntNSIOM: 


The concept of a reduced model has to be defined somewhat ey for static and 


for dynamic models. The two cases are discussed below. 
3.3.1 Reduced Static Models 


Before we can precisely define what we mean by a reduced model, we have to 
introduce some auxiliary concepts. A reduced model should: be free: of “extra” objects that 


cannot influence the externally observable behavior of the model. 


Definition 12. Reachahble Objects. 
A data object x is reachable in a model M with a sigaaliane S if and ne if there is 
some finite closed computation © with: respect ta’S such that’ xB the ‘value of C in M. 


Only the reachable. objects in the phyla of ® model-can influence ‘the externally observable 
‘ behavier of a model. | ? 

We would also like a reduced model not to contain redundant copies of the same 

object, if there is no observable property that can distinguish betwean fhe copies. Tp active at 

a definition for the external equivalence relation on data objects, we have to define open 


computations. 


Definition 13 meee Computation for a Legh sane 


jars pen computation with respect sgnaure Sand a type a < S-typenames 
is a finite sequence C such that 
Cli) = ( op: f, args : a) Ree ach Be Ave sang s 26 = eee 
where f <:5. opnames, and sits a sequence stich (hat - 
tength(s) = S. arglenth(/), 
- fj} (step za, te 27, resakt: &), where. 
iS <i, 
ifn =I then 5. argtypelf, = a; T= normal, and’ = 1, 
and if n >I then T ¢ S.tc(C{n]}. op) 

ISAS S.rlengthiCink op, 1) 

and S.rtype(C[n). op, T, &) = =Seareee 
for each j in the range I < j $ tength(s). 


An open computation is just like a closed computation, except that an initial data object is 


Prep ON aE 


Specified, which can be used in any subsequent step of the computation, in addition to the data 
objects produced by the preceding steps. The initiat data object is 2: parameter to the open 


computation, and the value of an open computation is a function of this parameter. 


Definition 14 Interpretation of an Open Computation in a Static Model 
Let M be an exception algebra model, let F = M. operations, let n = M.arglength, let 
C be a closed computation with respect to the typename a and the signature of M, let 
x € P., and tet HE be a sequence. Ii is the interpretation of the computation C 
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applied to the object x in the model M if and only if all of the following conditions 
hold: 


1. length(I) = tength(C) 
2. H{t] = ¢ normal, (x > > 


3. For each i in the range 2 ¢ i < length(C), 
I{i)} = Fa(xp. X78) ), _ where Cfi] = ( op : 8, args: s ), and 


4. For each jin the range 1 < j < n(A) 
Ry obj(I{k)) {w], where s{j] = ¢ step : k, tc: 7, result : w >, and 


5. te(Ii[k]) = 7. 

The interpretation of an open computation is like the interpretation of a closed 
computation, except that the interpretation of the first step of the computation is a sequence of 
length 1, containing the specified initial data object x, and with a normal termination condition. 
We have injected the initial data object x into the normal component of a disjoint union for 
the sake of uniformity. The ¢ tag, object ) pair is shown explicitly in condition 2. 

Definition 15 Value of an Open Computation in a Static Model 


If C is an open computation with respect to the type a and the signature S, M is a 
model with signature S, x ¢ M.phyla,, and if I is the interpretation of C in M with 


respect to a, then the value of C applied to x in M is C(x) = obj(I{length(IL))). 
The value of an open computation is the tuple of data objects resulting from the last step of the 
computation when interpreted in the given model. 


Definition 16 External Equivalence of Objects in a Static Model 
Let M be a model, a ¢ AM. typenames, and xI, x2 ¢ M.phyla,. The the data objects 


xl and x2 are externally equivalent if and only if for every open computation C with 
respect to a all of the following conditions hold: 


1. C has an interpretation in Af with respect to the data object xi if and only if C 
has an interpretation in Af with respect to the data object x2. 
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2. C has an interpretation in M with respect to Wins the value of C apulied to x} 
in M is the boolean vatue ¢ if and only if C has an interpretation in M with 
respect to xl and the value of C applied to x2 in M is the same boolean value be 
Two objects of a given model are externally equivalent if and only if exery qpen.computation 
applied to one of the objects yields a result that is ees from: the result of applying 
. the same open computation to the other “object. This means ‘that the two ‘byes share all 
externally observable properties, and therefore represent. the s same ‘abated object. even if they 
are two distinct objects in the model. The point is that the identities of the objects:in a model 
are not externally observable unless the data abstraction, provides some operations. that make 
them observable. , 
_ Now we are ready to define reduced static models. | 
Definition 17 Reduced Static Model 
A static model M is reduced if and only if all of the following conditions hold: 
1. For eachac M. typenames and for each x € M. phyla, x is reachable. 


2. For each a ¢ M.typenames and for each zi, x2 ¢ M. phyla, if xl and x2 are 
externally equivalent, then xi = x2. 


A reduced static model has no extra objects, since every-object is the resuk of some finite closed 
computation, and hence externally observable, and every distinct pair of objects in the model 
differs in some externally observable property. 

Theorem 2: Every equivalence class of models with respect to the behavioral “equivalence 
relation contains a reduced model. 

Proof : Take the reachable subset, and divide by the external equivalence relation. Details in 


Appendix HI. 
End of Proof 
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Theorem 3: If two reduced models are behaviorally equivalent, then they.are isomorphic. 
Proof : The isomorphism. maps the value of every, closed «computation in.one. model into the 


value of the same computation in the other model. Detaits in ‘eee HI. 
End of Proof 


Thus every constant data abstraction has a reduced model that is. unique up.to isomorphism. _ 
Theorem 4: If M is behaviorally equivalent to M' and M is reduced, then there is a 
homomorphism from a subset of M’ one M.. 

Proof : The construction of theorem 2 yields a reduced model. which is a homomorphic image 
of M. Compose that homomorphism with the isomorphism euaramcet by theorem 3. Details 


in Appendix IIT. 
End of Proof 


We can always find a homomorphism from an arbitrary ‘static model to a behaviorally 
equivalent reduced model. This result is interesting because the classical way to prove the 
correctness of an implementation of a data abstraction with respect to an abstract model 
specificaddén is to construct such a homomorphism from the implementation to the defining 
model. The theorem says that the required homomorphism exists for any correct static 
implementation model, provided that the defining model is reduced. While there is no 
guarantee that the homomorphism is computable or even finitely “describable, the 
homomorphisms corresponding to most implementations are quite tractable. As we shall see in 


the next subsection, the corresponding theorem for dynamic models is false. 
3.3.2 Reduced Dynamic Models . 


Informally, a model is reduced if it has no unnecessary objects. We have to take a 
different approach to formalizing this concept for dynamic models, because the existence of a 


data object and the properties of a data object are not completely determined by the identity of 
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the object, since they will in general depend on the system state: Theorem 4 fails for dynamic 
Models for this very reason. A homomorphism’ on a many sorted “algebra is a family of 
mappings, one for each phylum. In : dynamic model, the pre of fag: anys 
corresponding to the principal type of a dynamic data abstraction have no distinguishing 
Properties except for their identity. All of the interesting, properties. of an object belonging to 
such a phylum come from the image of that object under the system’ state function, and any 
particular object does not have any interesting properties until it is created (ie, until some 
operation gives the object a data ae other than undefined). Depending on how ‘an object 
gets created in each particular computation, an object in the model can come to represent any of 
a number of different abstract objects. Consequently, there may be no correspondence between 
the objects of one model and those of another which is both consistent with the operations and 
independent of the computation history. The cases where the correspondence is independent of . 
the computation history are rare. | 

The rest of this section consists of a characterization of a reduced dynamic waa xe: 
an example of two behaviorally equivaent models such that one is reduced but is not a 
sontenGhplte image of the other. - 

There are two requirements a dynamic model, must meet if it is to be reduced: the 
phyla must contain no unnecessary objects, sind for every sik the population must contain no 
unnecessary objects. If we insist that every element of every phytum must be reachable, the first 
requirement is met. Reachability can be defined for dynamic models in a way. entirely 
analogous to the definition for static models, and presents no essential difficulty. For most 
dynamic models a countable infinity of data objects are reachable, and each data object has no 


directly observable properties except for its identity, so that the first requirement is not very 
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antCrEStIN. | The second eaurenie®. femines a feckeewactacs new approach, because there is 
no mel to meaninguly 4 define the behavior of an abstract object independently of the system 
State. 


We wil assume that: an De mianays 2 a data abstraction. can |, create at Most finitely. 


4 Fo 2 
fs 


many new v data a objets ts. 8 Since we require alt pectations to terminate it ina finite amount of 


time, and since all real machines coe ata finite rate, bie repre dee fy is | justified. A 


Uy bye bY 


ai a of ths assumption i is that the populate of eal reachable state is finite, where a 
state is reachable if and only if there is some finite —- computation that produces, that state. 


We can define reduced models for aes models as follows. 


Definition 18 Reduced Dynamic Model 
A dynamic model M is reduced if and only if there is no other model’ M" such that ee 
M’ i$ behaviorally: equivatent:to “M, ‘aid’ (Gr Bie “closed” ‘computation C, the 
cardinality. of the population ofthe final'state prodded By'C i'M is strictly smafier 
than the cardinality of the population of the final state poeta by C in M. 


An example of a case where we have a rediited dynamic: model MI, and a 
behaviorally equivalent model M2 such that there is no homomorphism from any subset of M2 . 
onto MI! is described below. | 

Consider a version of mutable lists, ‘hick have sil as the only atom, and for which 
the rplaca and rplacd operations return the list that was ‘modified rather than ‘the did value of 
the component that was replaced, as is the case in LISR. . The! inodet MI has’ Pij4 =< N, and — 
Dist = { nil | UCN x N). In Af, the only operation. that extends -the population of the fst 
domain is cons. The eg operation serves to make the identity. relation on. objects in the model 
externally observable, so that every newly created. object-is distinguishable from any previously 


existing abject, and hence Ml is reduced. 
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The model M2 has Py, = Nand Aj. = cellt{ nl } UI (Wa x ML In M2, adit and 
rplacd as well as cons extend the population of Prict We have introduced : an extra level of 
we 

indirection, so that the identities of the abstract ae saleanae = the | puiithiae sib the cells 
that are the ‘data states of the elements of Pi rather than to the ements of Pus direct, as 
would be the case for any reduced model. Me is behavioral equiva to > MI, but m2 is not 
reduced, because the rplaca and rplacd operations create redundant us objects. | 
‘There can be no homomorphism from Me to MI because the correspondence b between | 


objects in M2 and objects in MI sapere on the sytem state. For example the e computation 


shown in Ct below 


CH = Cop : nil , args : 0). 
CH2] = Cop : + GOMS 5 AIRS : CGstep : 1, te: normal, result: 2, (sep 1,4: normal, result D)) ss 
CI3] = Cop : cons, args! (step :.1, te ; aaah belie Re ‘wees hax enacenaan 1)» 


“4 


has the following oe in MI: 


Ent) - (09.0) where o (0) = nil 
Hul2} = (0, ,1) where 0 (0) = nil, and o((1) = (0,0): 
Bit3}=<05,2)> — where Oo{0) = nil, ofl) = (0,0), and Oo(2) = (0,0). 


Cl evaluates the expression “(cons nil nil)". twice, resulting in two copies of the bist (nil) Each 
element of the interpretation Kil is a pair containing the results feturned by the operation 
specified by the corresponding step of the computation'Cl The first‘element of each pair isa 
system state function, and the second component of each pair’ is a nattiral number representing 
r mutable list. Note that. the ‘system state: is considered to be result 0, and that result I ts the 
first data object returned by the operation, corresponding to thie second: element of each pair. 


The computation Ci has the following interpretation in M2: 
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T2{t) = ¢ Oy.0) where 0,(0) = cell-0, 


Og (cell-0) = nil 
W2[2] = (0, ,1) where 0,(0) = cell-0, o,{I) = cell-l, 
0 (cell-0) = nil, o,(cell-1) = ¢ 0,0 ) 
Ti2(3) = « 05,2) where O9(0) = cell-0, Goll) = cell-l, Oo(2) = cell-2 


O(cell-0) = nil, 0 o{cell-I) = (0,0), 6 o{(cell-2) = (0,0) 


In model A12 we have an extra level of indirection. If the state 0,4, of MI corresponds to the 
state O ayo of M2, then we have the relation 0 gg)(n) = O ago(O qgo(n)) for any nc N (a natural 
number representing a mutable list). The correspondence between the elements of P),, for the 
final state produced by Cl in Af2 and the elements of the population of Pj,.¢ in the final state 


produced by the interpretation of Cl in M1 is 
M 
0 
1 
2 


Now consider the computation C2 shown below. 


Cll) = “op : nil, args : 0) 
C2[2] = (op : cons , args : (<step : |, tc : normal, result : 1), (step : I, tc : normal, result : D»> 
C2[3) = Cop : rplaca , args : <<step : 2, tc: normal, result : 1), (step : I, tc : normal, result : 1))) 


C2 computes the expression "(rplaca (cons nil nil) nil)". The interpretation of C2 in M1 is 


I21[1) = < 09,0) where 09(0) = nil. 
W2i(2] = <0, ,1) where 0,(0) = nil, and 0(1) = 0, 0d. 
. W2i{3) = <o,, 2) where 0'9(0) = nil, and Oo(l) = (0, 0 d.. 


The interpretation of C2 in M2 is 


- 64 - 


H22[1} = (09,0) where 0 g(0) = cell-0, and 


0 o{celt-0) = nil. 
¥22{2) = (o,,1) where 0'(0) = cell-0, a,(l) = cel, 


© (cell-0) = nil, and (cet) « = (0,0). 
E223) = (Gg,2) | where eo{0) + cell-0, ott) = ea, 6) = cell 
+ OefcelO)= nil, and 8 feet « = (0,0). 
Thus the correspondence. between the elements of the population of Pris | in M2 and the 
elements of Pg, in MI required in the final state prodhicéd by C2 is : 


Mi 
0 
! 
1 


A homomorphism must be a function, and hence single valued. Since the sie ga Cl and 
€2 introduce conflicting requirements for the image of the element 2€ Pry, there can be no 
homomorphism from M2 to MI. 

" Correctness cannot be established by exhibiting a homomorphism from the plementation $0 
the defining ciasitde) even if the defining model ‘ts reduced. ‘Therefore other methods of proof 
relying more directly on the underlying concept of behavioral equivalence are needed. Proofs 


of correctness of implementation are discussed in Chapter 5. 
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4. Specification Language 


In Chapter 3 we saw how a data abstraction could be identified with an equivalence 
class of models with respect to the behavioral equivalence relation. It is our thesis that an 
effective and useful technique for specifying a data abstraction is to explicitly construct a 
(reduced) model of the abstraction. The data abstraction denoted by such a specification is the 
class of all models behaviorally equivalent to the model that was constructed, which will be 
referred to as the standard model. In order to define a standard model for a data abstraction, 
we must specify the signature of the data abstraction, and give interpretations for its phyla and 
operations. In this chapter we present a number of methods for doing this, along with a 
language for describing particular models defined using these methods. Chapter 5 is concerned 
with proving that a proposed implementation is correct with respect to a given standard model. 

Since we are primarily interested in using our specification language for defining 
particular models, rather than for proving meta-theorems about the specification language, we 
have made no effort to keep the language rninimal. Our intent was to make it easy for people 
to read and write specifications in our language. Such a goal has no objective measure, and the 
reader is urged to consider our examples and to construct additional ones in order to judge the 
merits of the formalism. The syntax and abbreviations we have chosen are meant to ease the 
task of the human reader. For applications where mechanical processing of the specifications is 
to play a dominant role, a more restricted syntactic form may be appropriate. 

As mentioned in Section 3.1, we will construct models for data abstractions 
incrementally, assuming at each stage that models for all of the subordinate abstractions have 


already been defined. We will explicitly construct the interpretation of the principal type, and 


ae 
implicitly specify that the interpretation of each swbordiits ts is the siincigal type of the 
standard model for its s defining abstraction. 

In this Chapter we will assume that a model for a static data abstraction is an 
paneer algebra, and that a model for a data , abstraction with time dependent behavior is a 
state machine. (Recall that a state machine is an exception algebra with a distinguished . 


phylum of system states.) 
4.1 Components of a Specification — 


The important part of the specification. language. js. its structure and semantics, which 
are explained informally below. A precise definition of our somewhat arbitrarily chosen syntax = 
can be fotod in ens IV. 

The basic ; Components of a model specification are, iustrated by the example shown in 
Figure 3. This example gives a definition of immutable stacks (or. stack states), modeled. in. 
terms of sequences, where the top element of the stack is the fast peer of the seus 
representing the stack. This example has been treated many times in the fiterature on | 
specifications for data abstractions, and will probably be familiar to the reader. Later we will. 
see a specification of mutable stacks. The form of a specification and the meaning of the | 
components are explained briefly below, with occasional reference to the stack example. 

The name of the abstraction, which is the same as the name of the principal type, is 
introduced by the keyword type. An optional abbreviation for the name of the principal type 
is introduced by the end as. The name of the type is followed by an optional list _ of 
parameters, enclosed in square brackets. If there is a parameter list, then the specification is not 


a single definition, but rather a definition schema, which can be instantiated by substituting a 
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Figure 3. Stack 


type stack[E] as S 


requires E : type 
with empty: —>s % the empty stack 
push: ExS—S 
pop: S — S + (stack_underflow : > 
top: S — E+ (stack_underflow : > . 
null: S — boolean % is s empty? 


representation: sequence[E] 


restrictions: none 
identity: sequence[E]fequal 
operations: empty() = sequence[E]$empty() 
push(e, s) = addlast(s, e) 
pop(s) = if es = 0 then ¢ stack_underflow : ) %«@ is length 


else sf I .. (as)-1 ] %s{a..b)is subrange 
top(s) = sequence[E]}#last(s) 
nulls) = if es=0 then true else false 
end stack 


suitable expression for the occurrences of each parameter in the body of the definition. If there 
is a parameter list, there must also be a requires clause which specifies the restrictions on the 
expressions that may be substituted for each parameter. In the stack earls the parameter E 
is restricted to range over the names of types (E is the name of the type of the elements on the 
stack). 

The keyword with introduces a specification of the signature, in the notation 
introduced in Section 2.3.3. The signature gives the name and type of each externally available 
operation, including the number and types of arguments and the number and types of return 
values for each possible termination condition. The set of subordinate types is also implicitly 


specified, since it contains precisely those types, other than the principal type, that are used as a 
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component of the domain or range of seme operation in the aren Fach cueration ins 
also have an alternate syntactic form, which is introduced by the keyword as. “Within. the. 
definition of an arnt syntactic form, the expression = n” stands for the n-th argument to 

| infix, postfix, etc.), which are to beat ey ‘Tyee operations Ge. the name of its 
defining sears should be obvious from its context. In cases where it is not. obvious, .or 
where we want to emphasize the type, we wifl use the standard functional. notation, ‘where 2 the 


name of the operation is prefixed by the name of its defining abstraction followed. by a8” 


The parameters of the type will be included in cases whete that is help{ul to the (human) 


reader. : 30 

The interpretation of the principal type is ‘specified by the hexe three components. -; 
The arene eprescnatan aeeua is specified by an expression introduced by the keyword | 
representation. The allowable ‘expressions and their meanings are discussed below in Settion 


4.3 below. ne Festrictions component Species 3s. subset of the principal type ofthe -: 


representation n algebra, and the Identity section specifies an squivalence. relation on that subset. 


The Enerpretation of the principal type is the quotient of the specified subset of the principal 
type of the representation algebra with respect to the specified equivalence relation. The. - 
identity relation in cffect determines the identity of the abstract objects of the principal type of 
the aaysetion being defined, and serves as the logical equality relation for the principal type of - 
the ar Logical equality is not externally available unless oneof the. operations of the 
abstraction happens to coincide with it. In a reduced model, logical, equality should be. - 
‘Serany observable in fete of the operations, akhough not necessarily in terms of the same. . 


finite computation for all objects in its domain. 
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The operations are defined in a section introduced by the keyword operations. The 
forms and meanings of the operation definitions are described in Serton 4.2 below. | 

Comments can appear at au point in a pectin, They are introduced mes the 
symbol "% "and iii to the end of the line. 

Auxiliary functions or abbreviations may be used in the definition of the operations. 
The types of any auxiliary functions must be given in the internal section, and ne definitions 
of any auxiliary functions or subreviatices ‘nba be given in the definition section, in the same 
form as the types and definitions of the operations. Auxitiary fuinctiolie she arvcdacen ey 
for clarity and expressive power, and ies are not externally avaliaute (for use by programs) or 
even part of the model, which contains only the functions $ acting, as the interpretations se the 
exrenatly available operations. Auli functions wey be used in assertions ane in proofs of 
properties of the data abstraction. | | 

A specification is terminated by the sas baci end, ce flowed by the ‘site of 
the abstraction that’ was defined. In cases where several data abstractions are subordinate to 
each other it is necessary to define a group of related absractons by a ‘anes real with 
several principal types. In the specification language, a | module defining a model with several 
principal types consists of the keyword module, followed by any number of type definitions, 
followed by end module. The representation and..the: internal functions of each type are 


accessible throughout the module. Modules may not be nested. 


4.2 Defining Operations 


The principal type of a model is ane quot of the subset of the 1 principal type of the 
representation algebra satisfying the constraints specie in the idea taceccetette section: ath 
respect to the equivalence relation ee in the tdenty section. it there | is no restrictions 
section, the entire aloha es type is used. if there is no o Wentty section, aber me c logical op 
of the Principat type of ne representation ager is ud and the c quotient sricaure s Ever 
since all of the equlvalence classes are singleton in this c case. 

. The definitions of the operations in a type definition in our r speciation language 
explicitly define functions that operate on the ‘elements of ns pene type of id 
representation aigera These functions are mpi orca to oe on ame c equivalence | 
classes that make up the principal type of the quotient structure in the usual ‘Y: ee. in 
more detail in Section ae . 

7 The 1 following subsections eens: thet means: iad detning functions prover’: in the 
specication language and then examine bid conniare a fonction definition has to auey in 
order for it to denote a well formed operate for the exception ae or state machine being 


defined. 
4.2.1 Conditional Expressions | 


We will use a language for defining functions similar to that introduced by McCarthy 
in [33}, extended by the iota expressions described in the next subsection. 
A function definition consists of a function name, a list of variables, an equals sign, 


and an expression. Valid expressions are variables, iota expressions, functions applied to 
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expressions, and conditionals applied to expressions. Conditionals are written with the usual 
if-then-else sae and fia ete the usual resins | | 
& => (Cif & then x else 9) = x) 
~ b => ((if 6 then x else y) = 9). 

The variables that may appear consist of the variables appearing in the list of. formal 
arguments on the left side of the equals sign, and any local varia defined immediately after 
the function definition. A local variable is‘defined by writing its nae, an equals sign, and an 
expression. Circular definitions aré not allowed: it must be possible to eliminate afl of the ‘local 
variables from the right hand sidebf’a function definition by a finite nurhber of: substitutions, 
each of which replaces an occutrence of a‘ focal variable By the expréssioh defining it. Local 
variables are a notational convenience, in the sense that any definition using local variables has 
an equivalent definition without focal’ variables: ‘The abbreviations introduced by local 
variables can be’a very important aid in smaking-the'strlictaré’ of 'x Tunctior‘ definition more 
apparent to the human reader, and they can at'times dramatically strorten the text of a function 
definition. See 

The functions that may appear on the left hand side of an aperation definition are the 
primitive operations of the representation algebra and of its subordinate abstractions, and the 
operations and auxiliary functions defined in thé: type ‘spétification of: module in’ which the 
defining expfession appears. Recursive definitions are allowed. Auxiliary functions must be | 
defined in thé definition section. Auxiliaty functions caf increas’ the expressive power of the 
language, as proved for equational axiomatic definitiefs in: 2k °* This ‘result should’ not be 


surprising, since auxiliary functions may be defined recursively, so that the process of 


-72- 
substituting the body of the function definitions for each snvecaton (attempting to eliminate the 
auxiliary functions from the main definition) may ‘fail to terminate. . | 

Since the operations of a data abstraction are supposed. a be total ee: it is 


to ee 


necessary to show that all recursive Geftattions used are well founded. 
4.2.2 Yota Expressions 


lota expressions are named. for the ‘iota operator. in logic. An iota expression has the 

form x ; p(x), where x is the only free variable in the predicate p(x). If x is of type.7, and if the 
set {x € T | plx) } is a singleton set, then. the value of the jota expression x : fx) Seer 
element of that set, and otherwise the iota expression is.undefined. 

_ lota expressions are. useful. in cases. where it is much. easier to specify a property the 
result of a function must satisfy and to prove that the property. uniquely, determines the result 
than it is to provide a. recursive definition of the function. lota expressions are the equivalent 
of Hoare style input/output. predicates for a language with functions and without side. effects. 


An examples of a definition where an iota expression definition is appropriate is 
isqrt(n) = y 2 9% Sn < (ysl) 


which defines the integer square root function. . 
It is necessary to show that each iota expression used, in a specification is well defined, 
given the context in which it appears. More precisely; .the following two requirements must be 


Satisfied for each iota expression x : pix): 
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1 g(x) => Ax { px) } 


2. Way ( g(x) & pix) & gly) & ply) > x zy } 


where = is the equivalence relation defined in the Identity section, or the logical equality 
relation if there is no identity Section, # ranges over the principal type, and where gx) is the 
path predicate describing the conditions under which the iota expression can get evaluated. Let 
a be an occurrence of an iota expression in the expression e, and let path(a, ¢) denote the path, 


oa) 


predicate for a in e. Then path(a, e) is defin ed a follows: rahi 


path(a, a) =true - See 
if ¢ is “f(x, .., x,)" and a occurs in x; then path(a, ¢) = path(a, x) 


if ¢ is “if b then x else y" and q occws.ind , ...then,pathle,-«) = path(a, b).  ~ 
if ¢ is “if b then x else y” and a occurs inx —_ then path(a, ¢) = 6 & path(a, x) 
‘if. is “if & then x else y” and o occurs.iny then. path(e, # => b-&:pathle,9) 


4.8 Constructing Algebras 

Our approach will be to define.a standard modet for: a dete abstraction: in. tenms.of.a 
given representation algebra. The principal type of the.standard made! will in. general -be the 
quotient. of a specified subset of the principal type of the representation algebra with respect to 
a specified equivalence relation. The operations of the. standard model. will be.defined jn terms 
of the operations of the representation algebra, as described in the previous section. The.rest of 
this section is devoted to defining a tich set .of representation. algebras shatcaa:be.used as 
building blocks for defining models, 

Since it is not our aim:in the present. work. to investigate the foundations of 
mathematics, we will assume that. logic, truth values, sets, cartesian products, natural numbers 


and integers are primitive. An excellent formalization of these structures.can be found.in [48]. 
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We will use the notations summarized below. 

T and F denote the truth values true and false respectively. ‘These are the only truth 
values, and they are distinct. &, V. 7, =>, and = denote the and, or, not, implies, and equivalence 
operations on the truth values, respectively, and Vv and J denote. the universal aad. existential 
quantifiers. ¢,U,N, and - denote set membership, union, intersection, and set difference. Finite 
sets are written { x) .--,%», } and finite cartesian products or n-tuples are written (xp. Xy 
The i-th component of an ntuple X is written X 3%, so that (xy nna %p =x; The set of 
natural numbers is denoted by N. 0, 0, +, 6, <, and = denote zero, successor, plus, times, less 
than, and logical equality on y, respectively. The set of integers is denoted by Z, and +, % 7, 
quotient, remainder, abs, 2; and = deine pus, ties, tunaty) ‘minus oF (oinary) subtraction, the 
quotient and reapeomnern of integer: division, the ‘tosahete tatse Gpbiinie, the less than 
retation, and the equals relation, respectively. We rely on She context tp differentiate. between 
operations on the integers and operations on the natural pee with the same name. The 
usual qecimal netation: will be used for integerconstants, Which ate dinsidered to be an infinite 
class of nefary operations from the foritial point of View. 

We wif define a number of ways for defining algebras, namety finite enumeratioris, 
finite cartesian’ products, finite disjoint uftions, finite péwer' sets, finite sequences, and recursive 
definitions (fixpoint equations). The set’ of representation ‘algebras is defined to be the set 
generated by the standard model for the booleair digebfa defined below with respect to the 
constructions listed above (ie, the smallest set of algebras ‘that is thoted with’ respect to the 
constructions for generating new algebras). Each of the constructions supplies a set of 
operations as well as a set of data objects; so that we are generating a set of algebras rather 


than merely a set of sets. — 
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We also define two special purpose algebras, token and state[D], for use in defining 
the phylum of system states in a state machine model. Tokens and gaia have interdependent 
meanings, and are defined by a single module with two principal types. These two abstractions 


codify the ways in which the operations of a state machine can depend on the system state. 
4.3.1 Booleans 


We want to have an image of the domain of truth values as one of our representation 
algebras. Since everything else depends on the boolean dma (predicate operations return 
values of type boolean), we cannot use the methods described below to define it without 
introducing a circularity. We will define booties ti tetas of the si values in the 
underlying mathematics. A necessarily informal definition in a ickation similar to our 
specification language is shown in Figure ‘ Becsilses ihe wane of a data abétfaction’ is 
defined. in terms of booleans (cf. behavioral equivalence, Chapter 3), we insist that the booleans 
be given their standard interpretation itv-all models under’ disciission. 

Note that-the egual-operation on the booleans is the satiie as‘fogical equivatence on the 
underlying domain of truth values, which in turn is the same as the logical equality on the 
boolean domain. In keeping with our policy that the only externally observable properties of a 
data: abstraction. are those that ‘can be calculated in terms of the operations, we will always 
interpret "=" as the equal operation of the defining abstraction of the’ type of the data objects 
being compared. Thus it ts proper to tse “=" in thé definition of an operation only if the 


representation: type has an equal-operation. Care iiust-be tikef that the ¢gual operation of ‘all 


Figure 4. Boolean Abstraction 


type boolean as B 


with true: —>B 
_ false: . —> B: . 
not: BB as ~ arg! 
and: BxB->B as arg! & arg 2 
or: BxB—>B asargiverg2 — 
implies: BxB->B as arg i= arg 2 
equat: BxB-B as arg! - arg 2 


representation 8B = truth values 


operations true() = T 
false() = F 
not(x) = if x then F else T 
and(x, y) = if.x then y.else F. 
or(x, y) = if x then T else y 
implies(x. y)= (=x) Vy. : 
equakx, y) = (x => y) & (y => x) 
end boolean Gort  yaek GA'e 


the algebras defined is in fact an identity relation! Logical equality. is assumed to be defined 
for the structures that have been. imported. from. the ; vaderlying ssathetiatice such as the 
natural numbers. 

The boolean type is isomorphic tothe. dorsain of truth values in-the underlying Jagic, 
as indicated by the interpretations of the operations true and false in the standard model for. 
_ the booleans. The operations of the representation algebra correspand to. those of the 
propositional calculus in the underlying logic. Quantifiets.are defined only in the wnderbyierg: 


logic, and have no counterpart in the representation algebra. We will make heavy and irapticit 


I. An identity relation egual must be reflexive, symmetric, transitive, and must satisfy the 
substitution property equal(x, y) => P(x) = P(y), for any predicate P. 


a 
use of the isomorphism between ne booleans and the underlying domain of truth values, so 
that the primitive predicates of any representation algebra, which return values of type boolean, 
can be combined with quantifiers, and used in Ue anerrelse baal both of which are 
defined in terms of the underlying logic. The booteans are the only pe for which we will talk 
about properties of the interpretations of the objects directly. ‘For all other types we will talk 
only about the results of applying the primitive operations. The only direct connection to the 


underlying mathematics is by means of the booleans, which is why that ne ig: ‘given a 


distinguished status. 
4.3.2 Natural Numbers and. Integers 


We import the systems of integers and natural numbers directly from’ the underlying 
mathematics. Definitions of these types are given in Appendix Il. These definitions serve to 


sii down the syntax, and have nothing surprising in them. ardapy Bak 
4.3.38 Emumerations 0. 2. .w. ts 


Enumerations are useful for defining small finite sets, such as characters. Larger finite 
sets, such as fixed length integers, are most conveniently described in terms of the infiaite ete 
‘they are intended to animate as will be illustrated later'in this chapter. 

An enumeration {x i ek defines an sirens whose principal pe is a set with n 
elements, ai whose only subordinate type is boolean. ‘The algebra has i nuilary operations, the 
constants x; for 1 <i £n, and one binary operation, equal, which ‘allows the elements of the 
principal type to be distinguished from each other. We want equa, x) to be true if and only 


if i= 7 The indices range over the set of natural numbers W. There are many models that 
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Figure 5. Enumeration Types 


type { x). .x, } as T 
with x; PF 8s for Soe 
equat: T x T — boolean 


representation: natural numbers 
-pestrictions: isuch thatl <i<n 
identity: = 


operations: x0 =i . fori<ic<n 
eguaKa, b) = ff'a = b then true élse false i 
end 


exhibit the behavior described above. ‘Our Scindatet model! shown’ in Figure 5, uses natural 
adie to Tepes | ihe cereus of the enumeration. The'= “= a: cabbie used in defining the 


seul operation of the enumeration m type denotes the he equal operation: of the natural numbers. 
4.3.4 Tuples ; . Be Ee ee IS Aes ie SERS ORE Sed Tad Sus 


Tuptes are labeled finite cartesian products. We will write tupleta, * 5) a Wn: S,) 
for the set of n-tuples such that the i-th component is a member of the set 5, and bears the 
abet w,. for each i in the range i<i < n. We will write ¢ My: Xp sees My Xq.) for the tuple 


containing the elements Mp aX 


tx. ,The projection, function mapping a tuple fo its i-th 


component is denote by plw;), and if tisa tuple, then plu Xe) can be abbreviated. as to w,. If 


Ba Bar et ted Xp loa eke for enemy tie Ue SAN ae .. Two tuples are 


a chat 


equal if and only if corresponding components are ogee Equality of tuples is defined for the 


type. tupie[w, Sige :S n) if and only if the defining, algebra o 5; has an equal operation 


for each i in the range | <i £ n which is an sdesihy relation. If some of the component types 


Figure 6. Tuple 


type 
requires 


with 


representation 
restrictions 
identity 


operations 


end tuple 


tuple[w, Spay Wy: 5,1] 
5; : type 


construct: 5p xX. x 5, —>T 


plo} TS; 

equal: T x T — boolean 
T=5,x.x Sy 
‘none. 

equal 


construct(x;, ... Xx n) = ¢ Xy snip Mp ) 


plw,Kx) = x 4 


as T 


fori<icgn 


__ equakx, 9) = if VIL S iS n =x. w, = 9. m, ) then true else false 


ftishyilk SHOE 


do not have equality operations, then the tuple type does not have an equal operation either, 


although the type and all of the other operations on it are well defined. 


This description is summarized in Figure 6 in an informal notation... Recall that 


cartesian products are primitive, and that if x is an -n-tupte, then: x 1 i denotes the fth 


component of the n-tuple. 


2. An equal operation will be defined for every representation algebra ‘in our basic set. 
also possible to construct tuples with components on user og types. which need not have 
an equal operation-(e.g. stacks).. 


jt is 


4.3.5 Oneofs 


Oneofs ; are finite labeled dijon | malont, A oneof is the dual bel a tuple, in the sense 
that the projection function, | gO in the other direction, Wa will write eet Sp, Wy? Sy) 
for the disjoint union of the ‘sets 5),..,5 : Our standard model for 
oneofia, : Sy, Wy, :5,] shown in Figure 7, uses the sit sete, WS ia repeesent the 
principal type, which coincides with the standard interpretation for disjoint unions used in 
classical mathematics. Each element of a disjoint union is represented as a pair containing ani 
element of one of the component types, and:a label indicating whic? aan the element 
came from. If an element occurs in more than one of the 5,, it will occur in sacral dicinet 


efements of the i a union, iene a different values for the label | component. of the 


fei 


pair. 

tyne onenfin, Spy S,) sO 

requires 5; : type : for lsd sa. 

with inlw,} 5; 0 asargiinw, forisicn 
tolw,} O—> 5,+(wrong.type:) asargitom, forl<icn 
islw,}: 5; —> boolean asarglisw, for!<isn 
equal: O x O —> boolean 

representation O- U_ { w; }x 5; 

ISiSn 

restrictions none 

identity = 

operations inlw,Kx) = ¢ wy; x ) 


tolw Ko) = if ol 1 = w; then o | 2 else ( wrong _type : > 
islw; ‘Xo) eifoli= w, then true else false 


equaKol, 02) « if (ol 1 = 02 41 & of b 2 = 02 4 2}then true ete false 
end oneof 
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A oneof type has n injections from the component types into the disjgint. union,-n 
predicates indicating whether or not an element of the disjoint union came from.a given 
component, and 1 projections, which retuin the element’ without the label if the label 
corresponds to the component of the projection, and which termiriate, in the wrong_type 


exception with no return value otherwise. The oneof type. has an equal operation if and only if 


qe PS 


each component type has an equal operation. 

i we shall see below, one of the main uses for disjoint unions is in constructing 
recursively defined types, such as trees. 
4.3.6 Sets 

We will write setlE) for the domain OF finite ‘sabsets ‘oe the, type E. An informal 
definition of set{E] is shown in Figure 8. This construction is valid only if the defining — 

abstraction of the type E has an egual operation that computes ab, identity relation, because 
equality is necessary for deciding set membership. There's gre muftary operation which returns 
the empty set of the given type, and there are operatioyis for adding and removing elements, 
and for forming unions, intersections, sét differefices, and restrictions ‘There are also operations 
for testing to seé if'an elemenit belongs toa given set, if one set is a subset of another, if two sets 
have the same members, and for finding the ie of a set! Which is always defined because we 
are dealing only with finite sets. Set restriction is'tredted as in indfefinitely large parameterized 
farnily of operations, where the paranieters are ine bind. viable and the body of a lambda 
| expression defining a predicate ie: a fancies ‘i E to boolean). The size of a set is defined 
to be an integer rather than a natural number, so that sizes-can be subtracted and divided. 


The natural numbers and the integers:are defined in Appendix Il. 


Figure 8. Set 


type set{E} as S 
requires E : type with Efequal: E x E —> boolean such. that. 


with 


representation 
restrictions 
Yaetitity © 


eperations 


definition 


end set 


null: _ —>$ eres 

add: ExS—>S 

remove: | ExS$S 0 a ae, aes ee 
union: SxS—>S as arg!U arg 2 
intersection. SxS->S .......... gxargi fang2. . 
difference: SxS7>S as argi- arg 2 
restrictix, p(x) S—>S —- ae Ex: arg Ul plx)} 
empty: © -- S —> boolean 

member: ExS—>boolan id... ag erg ¢.arg2. 
subset: S x S — boolean as arg!¢ arg 2 
equal: S x S —> boolean as argi- arg 2 
size: S — int as|aergij.. 


S = mathematical sets 
s such that : $ Ss E and cardinality(s) cw. 


equal 


nuiK)={} 

add(e, s)=sU fe} 
removede, s} = 5 - fe} 
union(s!, $2) = st Us? 


"“intersection(st, 3) = sf fi 2 " 


difference(sl, s2) = si - s2 
restrictlx, plx)Ks) = [x ¢ st pad} 
empty(s) = if Ix (xcs Ithen fabe eke true 


~ member(e, s)< if'ec s then true else false 


subset(sl, s2) = if Tx Lx ¢ sh & 7 (x € 52.).] then false else true 
equal 2) =f (31.12 8 a) cet tree ee foe 
size(s) = cardinality(s) - eae 
ident_op{) = Vx (f(x, x18 Cue Riek te Se ek ee 
Vx.y E fx, y) => fly, x) & 
Vx.y.z [ flx, y) & fly, 2) =? fx, 2) Joe 
YP i As Re mn 


In Figure 8, a definition of finite subsets of a type E is given.in terms of ordinary set 
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theory. The notation in the figure is ambiguous, because we wish to use the standard notations 
for the usual set operations as abbreviations for the operations of the representation bk Sai as 
well as for the set operations of the underlying mathematics The ambiguity is: resotved as 
follows: within: the. definitions of the atl ly the standard ‘set ‘notations refer to the 


a 


operations of the underlying mathematics, while the as ae in the signature section redefine 
_ those notations as- abbreviations for the operations 0 of! ~~ Fepresentation algebra, for external 
use (i.e, when using representation algebras.from the set fainily to define standard models for 


other data ebutrettions): 
4.3.7 Sequences 


We will write sequence[E] for the domain of finite sequences. of. elements of ‘type E. 


An informal definition of sequences in terms of cartesian products is shown in Figure 9. 


Another definition, using a fixpoint construction, will be sketched ithe next section. 

Sequences have an exceptional termination: ‘coridition, ands Which is associated with 
attempts to use elements of the sequence that oo) not exist Sequences ant ‘be decomposed into 
the first element and the See Containing a alt bt the “Hirst element, and also into the last 
element and the ssiacita: ‘of all-but the. last element, so that neither end of the sequence 4s 
preferred with respect to ease of access. Subtaigel ate Specified by. giving the first and fast 
elements of the subrange in the original sequence. The length of a subrange slab) is 
1+b-a. Subranges with strictly negative lengths ‘are not defined, and an attempt to construct 


one will result in a bounds exception, with no return value. 


Figure 9. Sequence 


type sequencelE} asQ 
with emptyseq. 39 > Q. as () . 
addfirst: QxE—>Q ‘as arg 2 +) arg t 


addiast: QxE>Q as arg! |» arg 2 
butiast: Q->Q 


append: .QOKQ--Q as erg if arg 2 — 


subrange: Ox a sents Choeed: ) as argi([ arg 2... arg3) 


_ prefix: Q x iat > Qs bounds: > «= asviargtf.. arg 2) 


representation. 
restrictions 
Identity 

_ operations 


suffix: Q x int > Q + ( bounds : > as argi({arg2..) 
element: Q x int — E + ( bounds : ) asavgti({arg2) - 
first: Q-> E+ (bounds : ) 

last: Q— E+ (bounds: > 

length: Q— int aséerg! 

empty: Q-> boolean 

equat: 2 * boon as arg! - arg 2 
sare fepoeBi ccc OB Lis the length 
ane nee 

sequencefequal 

emptyseq() = (0 ) 


addfirst(g, e) = (1o(eq),e , qlll .., afeq] 


— addlastig, €) = Ci(eq), qUih..qlegh e > 


butfirst(q) = q{2 .. eq] 


_burlast(q) = af)... (eqht) 


append(q, r) = if oq = = Othenr : 
eke ifer=Qtheng  . 
‘else ( (eq)o(er), qUil, .... qleqh rill. vetoed > 


subrange(g, i, j) = if (i < DMG > shy eh then, beads 


end sequence 


else if j = i-I then (0) 
4. ee 4 eft, Ml. qdil> 
prefix(q, i) = qll .. i) 
suffix(g, i) = qfé ...eq) 

element(q, i) = if (i < Dvir , #9) then (bounds : ye 
_—_., ebse g F (ted) ; 

first(q) = qfl} © 

last(q) = qleq] 


Jength(q) = q J 1 


empty(q) = if 9q = 0 then true else false 
equal) = faq = er VELTE 1S oq = afi = iJ then true ele fase 


4.3.8 Fixpoints 


It is convenient at times to introduce algebras whose principal types t have a “recursive” 
structure, such as the algebra of binary trees. aval it is dcop: ta oes isomorphic sages 
of such aera using just the machinery introduced so far, by introducing apenas 


encodings into the natural numbers, such a srategy does not contribute to the clarity of the 


resulting specifications. Instead, we wil introduce “opi poe e * (aires) domain 
definitions, which are considered as fixpoint equations over the domain of all algebraic 
structures. 


The hepresentavon component of a eae will a me a domain Peat: 
In cases where the name . of the algebra being defined Bors not Reppeae on. both as bal me 
equation, there is always a a ae solution, since we are cena solving for the fixpoint of a 


2543 


constant transformation. In cases where the representation algebra is defined in terms: of itself, 


} 


there may ‘be many ¢ different solutions to the equation. Following Scot46) we wilt introduce a an 


é Pray is souir 
Bey) “ged Pay 


ordering, and say that a aeaia equation ¢ denotes she mininet soi with: nespeet to that 


y reset 


ordering. We will use the poiniule containment ordering on algebras, denoted by © c, cane 
: * a . = 


ee, 


defined below. 


Definition 19 Pointwise Containment z . 
Let a and b be ee Thena fb if ane d only if all of the following conditions 
hold: 


a. typenames C 6. typenames, - 

Va ¢ a. typenames [ a. phyla, & 6. phylag h 

a. opnames € bs opnames, a. we 

V6 ¢ a. opnames [ a. pperationg S b. opertionsg ho 
a. tcnames ¢ 6. tcnames, 

a. arglength ¢ 6. arglength, 

a. argtype ¢ b. argtype, 


atc ¢ b. tc, 
a. riength ¢ 6. riength, and 


Go ttype: © 6. stype: 

a pe ¢ 6. pt 
Iffac b we . wilt ay that a is ‘contained in 7 This means vibe for every, y phylum - a, b ae a 
phytum. of the same name, and for every operation 0 om 4, .s has an operation tala the same name 
and type: Every phyhim of a isa , subset vl the coregonding phylum of 6, and every operation 
of a isa restriction of the corresponding operation of 6. The ee bea Sak b ay nave types 


and apierations not i present in a. The set of vvimcipal ines for a must be a subset of une set - 


gH 


oe types of b. 


Note that C is reflexive, transitive, and antaynetee and hence is a 2 paral ordering 


a pees F 


Pelstion: Because © Cj is auayrmeti, ifa ‘osetonel sohution« to a fixoin equation exists, ft must 


z? 


be unique, if we restrict ourselves to o expresions bulk from continuous Aven respect to ©) 


oe Fs 
oesake ai 


transformations on n algebras, then ‘the ‘existence ov a solution | is ; guaranteed byt Keene's firs 
recursion theorem [231 which also gives us an an exp I frrul fr the so shtion, 

| " Kieene’s first recursion theres: states that if the anstecvei ict F fs continuous with 
respect to c then FF) « YF, cand YFE cA Eee) F(A)» A white YF = wel F'(1), u 
denotes the least upper bound with respect to ©, FA) = A, Fi*HA) « FOFUM, and where i 
‘denotes the least element with respect tof. In other wands if y exit HP is the nan ae 
of the transformation F. In order to show that VF exists, ia sufficient to show that there is an 
algebra 1 such that 1 © A for every algebra A, ame that ven chontey with respect to © has a 
least upper bound in the the domain of all shemale agers, It ieey to see that 1 ones: it 
is the algebra with all components equal to the ennpty ‘set, containing Ro et and no 


operations. 


- 87 - 


Theorem &: Every chain with respect to © has a least upper bound. 


Proof : Take pointwise unions, details in Appendix II]. 
End of Proof 


In order to use this result, we need a means of defining continuous transformations. 
This is also easy, because all of the methods for constructing algebras introduced earlier in this 
chapter are in fact continuous. The reasoning required to establish continuity is illustrated for 


the tuple transformation. 


Theorem 6: The tuple transformation is continuous with respect to E. 


Proof : tuple preserves pointwise unions for chains of algebras. Details in Appendix III. 
End of Proof 


Since all constant transformations are continuous, and since the composition of two continuous 
transformations is continuous, it follows by an easy induction on the depth of the nesting that 
any expression composed from the constructors for spaikeritiods tuples, oneofs, sets and 
sequences defines a continuous transformation. Thus a minimal solution is guaranteed to exist 
for any domain equation expressible in our specification language. 

In order to make sure that the transformations defined earlier in this section are 
monotonic with respect to C, we have to be a bit more precise about what the transformations 
are. (If a transformation is continuous with respect to €, then it must also be monotonic with 
respect to €.) 

We will add an implicit parameter to each of the transformations, which specifies the 
name of the principal type of the algebra resulting from the transformation. The construction 
of the principal type and of the operations on the principal type has been described above. 


The subordinate types of each input algebra are included as subordinate types of the output 
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algebra if and only if they have a distinct name from that given by the implicit parameter. 
The names of the operations on the principal type are taken ‘roe the definitions ‘of the 
transformations, and prefixed by the name of the principal type to make sure they are distinct 
from the names of the operations on the subordinate types. 

For any composition of tuple, oneof, set, and sequence constructions, the implicit 
name parameters are to be chosen so that every occurrence of each constructor in the expression 
is given a distinct name paris and so that the ime parameters are distinct from any of 
the names of any constant algebras occurring in the curiae With this proviso, any 
expression that can be formed from the tuple, oneof, set and S adenes ‘renitnmadonn and 
any algebra constants will be monotonic with respect to &. It is aéso easy to see that the new 
phylum defined by a fixpoint construction will have. the same name as its image under the 
defining transformation, so that the principal type is buik up: by successive approximations, as 
usual for a solution to. a fixpoint. equation. Also.note that as. defined above, each of our 
transformations maps complete madels inte complete madels. 

An intuitive justification for choosing the minimal solution toa domain equation is 
that we would like our. standard model to be reduced (i.e, free of unnecessary ‘data: objects)... 
The explicit solution to the fixpoint equation can also be used to argue that the minimal 
solution is exactly the solution we would like to obtain, because it contains all of the objects that 
are finitely constructible using the operations of the representation algebra, and oaehers To 
see this, note that any operation can produce a.data object:in a domain F4(1) with an index 4 at 
most one larger than the index of some. domain. containing. an. aegument of that. operation: {or 
one if there are no arguments). Therefore the results of. some finite-computation in terms of the 


primitive operations can produce elements of F*(1) for finite natural numbers i, and all of those 
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domains are contained in the principal type of YF. Conversely, if our transformation F is such 
that every element of the principal type of F(A) is {initely constructible whenever all of the 
elements of the phyla of A are, tne so are all of the elements of the phyla of YF, since the 
principal type of YF is just the union of the Principal, types of all of. the algebras.in:the chain 
F(1) 

To illustrate the use of recursively defined, Tepreseniation algebras,. consider the 
definition of pensar binary trees shown, in Figure i 10. c PUTA. is a family of data 
abstractions, parametrized by the type of the leaf nodes of the tree. The leaf operation creates. 
a leaf containing a cgien, element of type E, where a leaf is a kind. of binary_tree.. The tree 
epertion constructs a compas ite: tree with ha teft and right subtrees... 7. he left and sight 


operations return the left ant ri ht euptice of a con ite and terminate. in. the no_subtree. 
a mer yee, a 


Figure 10. 


type binary_tree[E] as T 
requires E-type Se 


with feat, 8 ET oes 


tree: TxT~>T 

right: T > T+ (no_subtrees 9 
left: TT + Cno_subtree : ) 
value: T — E+ Cnot_leaf: > _ 
leaf?. T — boolean ar 


representation T = anect leaf : E, Pitan ret ne Pent: qT No 

operations leafle) = =ein ie 
tree{x;.y)'= (eft: x, right: y) in tree” 
right(x) = if is{leafXx) then ( no_subtree : ) else toltreeXx). right 
Veftéx): « if: ie{hea fk) then: ¢ no sabliee:: ¥ else toftreeKx). left 
value(x) = if is{leafKx) then tofteafXx) else = not, t_teaf : > 
leaf{x) = if-isiteaf Kx) then trie‘else false? 

end binary_tree 
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exception with no return values if applied to hast The predicate leaf? tests a tree to 
determine whether or not it is a teaf. The value operation extracts the element contained in a 
leaf node of the tree, and it resuks in a not_leaf exception if applied to a conpoeite node. | 
There is no qualitative difference between defining the operations of a model whose 
representation algebra is defined by a fixpoint construction and defining the operations of a 
mode! whose representation algebra is defined by some finite composition of tuples, oneots, sets, 
and sequences. The domain equation specifies the structure of the representation algebra, and 
icupticicly also, thé operations avilable on. the: kepiiscuatien ‘algebra, airics- each uf the 
transformations mentioned above saaraclces some ‘operations. For example since the 
representation of a binary_tree is a oneof, the projections, injections, ‘and domain test predicates 
of the given oneof type are available for use in defining the ‘operations of binary. tree. This 
uniformity is a consequence of the fact that the representation algebra is an exact solution to the 
domain equation. | 
The fixpoint construction can also be used to construct the natural weenie nulithve 
parameterized family sequencelE] A convenient representation algebra for defining ‘the: 


natural numbers is the solution to the equation 
nat = oneof{[zero : { 0 }, nonzero : nat]. 


This equation is based on the fact that each natural suaber is ether pan or it is me successor | 
of some other natural number. Thus zera.is represented.as the element of the ay chosen 
Singleton enumeration type { 0 h and any. other natural number i represent its predecessor 
injected into the nonzero component of the disjoint | union. This works. because each injection 


adds a tag to sikee the elements of a disjoint union distinct Thus zero is renesenied by the 
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pair (zero,0), one is represented by the pair ¢ nonzero, ( zero,0 >), two by the pair 
(nonzero, < nonzero, ¢ zero, 0) ) , and so on, where the natural number n has n tags equal to 
nonzero and one tag equal to zero. A representation algebra suitable for defining sequence(E} 


is defined by the following equation. 
seq = oneoflempty : { \ }; nonempty : tupieffirst : E, rest: seq) : 


The reader is invited: to ‘fill in lod details of id fast | two emers: to get some experience in 


working with recursively defined on algebras, 


Another treatment of freeusively defined comalts: can be found in (2, 25) We preter 


to avoid a category theoretic formulation, on the © grounds that the ie ubjet can we treated 


ae: it 


sauihcorly in terms of a more widely k known mathematica sing. 


be 


4.3.9 System States : ee ee 


In a state € machine model, the ¢ current pico state e function is the disjoint union: of aad 


sh ye 


current individu State functions for each mulsvre pe When rei tes a state ache mouet 


zghy 


in our specification language, we will expily construct tony the individual state dunetion for 


g ca eae | 


the Principal ne The indiviciia} state functions for the subordinate types are taken from the 


Spee 
ft i 


standard models for the defining abstractions of ine suporainate types, ~~ the obj unions 


of the individual state functions required to eet a sytem state tegen 4 are le implicit, 


vas 


We Spears two ppsaclony fone ane states, for use in constructing. the principal , 
type and the individual state inettons of a state matane model. The interpretation of the 
principal type of a state machine will always be the scantiget ‘ype of the token abstraction, and 


the set of individual state functions for the principal type of the state machine will always be 
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state[D], where D is the set of data states for the sate machine. 
The token and state[D] abstractions are defined ay the standard model shown in 
Figure il. These abstractions have beer defined : so that ¢! the ov propery of: a ‘token that is 
externally observable is its identity, by means of the tokenfequal operation. ‘The cal way to 
create a token or to extend the papulation of the..principal type-is. by means of the state 
extension Op SratOn: | 
‘The only way to extract any information from an individual met function is * sate 
it to a token to get the current data state of that ‘ke 1 Wall aces whe sate of a ecaie 
limited to the operations es by the | state absraction, ‘then we can be assured that ane 


TP 


only state information in a state ‘machine Is that as associated pean the : Individual ‘data 2 objects, 
thus enforcing the assumption dicsed in Section 32 ‘hd in ‘Appendix I. - 

New states can be created by the init, extend, or spidais oe The tait_ operation 
creates an empty state. This epost has been inchided ne completeness, since it is ies i 
to define the initial. state e of the State machine. The statebenend spuationia creates a new state 
in which the data states of alt previously existing 7 ata ob objects a vate, and in which a 
new data ‘object | has been created, with a given value as ie its initia data state. This ib operation's is 
used to describe the dynamic creation of a data objet The ¢statehupaate operation contre 
a new state ‘differing from the old ¢ one € only at a 2 single pont in its domain, and it is used to 
model operations that change the properties of some Ligeia jain objec. — 

In addition, ‘there is an internal fine statefused, which | tests ‘whether a given 
token has ever ‘been created in a ven state. This function ¢ may not be sed in n defining the 


operations of a standard model, but it is useful in  sisertions: and  prots about dynamic data 


abstractions (see Section 5.4). Note that the used operation wills say that an object that has been 


Figure 11. Tokens and States 


module 
type teken. . as T 
with - equa: : T x T — boolean 
representation int 
restrictions x such that x 2 | 
identity | equal 
operations. equati, j) = if int#equaXi, j) then true else false 
end token . 
type state[D} asS 
requires D : type 
with init: —S 
extend: Sx D->S x token 
update: S x token x DS + : undefined_object : > 
apply: - S wtoken De eet» estarg tC arg 2) 
representation. $= sequencelD) 
restrictions none 
identity... sequencefequal . 
operations init)=() eo tae 


extend(s, d) = (5s |+ d, 7 + tes) 2 

update(s, t, d) = if 1 <t < os then sf .. (t-1)) f+ dof sf (tel). ) 
else ( undefined_object : ) 

apply(s,) = if 1 < tS as then sithebse undefined —— 


internal J sed: token x.S -> boolean. - 
definition used(t, s) = if 1 <t < es then true else false 
end state 

end module 


created and then destroyed (by changing its data state back to endefined using stateSupdate) 


has been used, so that in general the used operation does not say whether a given object exists 


oie 
in the current state. (For secure data abstractions, the two notions suaclie 
The reason for defining tokens and states in the same module ‘isto limit ‘cae toed 

ipitatics on tokens. Note that the definitions.of the sate bperations use the representation of 
tokens, which is available throughout the module, but not outside it. If tokens mete pes in 
a Separate module, then the FepTesentallcn woukd not be accessible, and additonal operations on 
tokens would have to be provided. 90:that the state operations could be defined. However, we 
do not want modules other than the definition of the state abstraction to have accessito any 
operations on tokens other than equal. We freely admit that this is an ad 4yoc solation, and we 
refer the reader to (21) for a description of a general access cate mechanism for data 
abstractions. Rig aa . : Gates 

AR indtviduat sista) onetion is reAreiedta Une On the specie value undefined 
except at a finite number of tokens. This restriction assures‘tsrtiat:the domain of systent states: 
is countable, even though it is a function space on an infinite-dgemini: uh mn ree 
is that we have no need of limit constructions or transfinite inductions ‘in reasoning  #beut 
system states. ae es 

A state machine madel.for.the sniquecidwbstraction is shown iti Wigure 12. Since the 

specification has a data states re ganes ten = aerrecente component) we e‘khow 
that a state machine is being defined, father ‘than an exception cea and that rhe 
representation of the principal type is implicitly defined to be the token abstraction defined An: 
Figure ll. In this case the set of data states is a singleton enumeration type. At least one proper 
data State-is needed to distinguish she objects that: have been created from those that have net 
been (and: have the data state undefined), Unique.ids:are immutable:(once a unique_td has _ 


been created, its properties are fixed forever), so that one proper data state is all that is needed. 


ee <a bs) = 
Figure 12, Standard Model for Unique-id 
type unique_id as U 


with create: —>U oo ° 
equal: — U x U — boolean | 


data states D ={ null} : os ie oe 8 
operations create(sX) = extend(s, null). 


equaKs\x, y) = (s, v ) 
where | . vif tokenfequatx, y) then true else false 


in Es 


end unique_id 


This example serves to ‘illustrate the state change caused by the creation of a new data object in 
its purest form. The unique_id abstraction is secure, since there are no operations that ‘destioy 
- unique_ids. 

A state machine riiodel for a memory cell contalhing a single object of type E is shown 
in Figure 13. Cells: are among the simplest mutatite data” abliractiiiis. “Thie’create’ operation 
returns. a riew cell with a “specified initial céritents. “NOt that’ thé’ state¥extend’ operation 
returns a pair of values, contaifing the fie ‘stite’arid'a token fepresenting the newly created 
object. The new state’is the first return Vallie’of every operation’ Of'a State machine mhodel, and 
the old state is the first rgiiment. [h an implemidtitation, the state's passed around implicitly, 
while it is explicitly represented’ in a state ‘machine ‘Model. “THiS is Feflécred in the signature, 
whith has no mention of | the state, and ‘describes ofily the type structure Visible externally. The 
update operatidn returnis Ad data objects, but it produces a new state in which the given ceff has 
a new value for its contents. The contents operation returns the current contents of a cell, and 


the equal operation tests to see if two cells are identical. Beth of these operations do not modify. 


Figure 13. 
type celi{E] as C 
requires E : type 
with create: E>C_ 
update: CxE~> 
contents: CPE 
equal: CcxC— boolean 
data states D=E 
operations create(sXe) = extend(s, e) 
update(s\Xc, e) = state[D Mupdate(s, c, e) 
contents(sXc) = ¢s, s(c) > 
equaXsXcl, c2) = ¢s, ¥ ) 
where = _. V = if tokenfequalicl, c2) then true else false 
end cell 


the system state. If we. view cells as the L-values of the variables of a_programming language 
[cf. 50], then the equal operation can be used to determine whether or not there is aliasing 
between two variables: an assignment.to one variable (a celfupdate operation) will affect the 

Note that there is. no. iui as an uninitialized cell. If hee wanted to define.a 
different cell abstraction, in which cells could be created without being, initialized, then we 
would have to introduce an additional data state to indicate that a cell was uninitialized, since a 
token with the data state undefined represents a cell that has not been created yet. Since we 
require the operations of a data abstraction to be deterministic, an attempt to find the contents 
of an uninitialized cell would either have to result in an exception condition, or in some 


constant default value. 
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4.4 Well Formed Specifications 


A. specification és well formed af it denotes ‘some exception algebra or state machine. ° 
This will be the cate éf the requirements déscribed’ inthe following ‘subsections are met. In 
addition, a, reasonably defined: data abstraction shoul ‘satisfy: the follewing two ‘constraints 
{cf. 41,10]. Wit ae, Saabs oe Se 
Every operation of the abstraction d should either, saplc at least one argument from the 
principal type of d, or it should produce Scala rein value tiie the normal termination 
condition) from. the principalsype of vt for fron dome prindipattype af there iy thore than one). 
The purpose of this--constraint is to rule out functions ‘that: have nothing to do with the 
behavior of the principal type. | = 
There showid be: at least one operation that preduces''a Value ‘betonging to the 
principal type which does not take any arguments from the principal typé. ‘If this constraint #8 
not met, then there is no way to compute any ‘values of the Lhaea: ane type, and thus. ithe 
interpretation of the principal type in a reduced ntl wincen empty set. 
Note that both of the above constrainas cay ‘be-easily clhiecked giver’ just the signature 
of the data abstraction. They can‘be viewed ‘as-constraints a:stracttre’ most’ satisfy: fn order’ to 


epepge 
oars ie = 


qualify.as a meaningful data’ abstraction. 
4.4.1 Type Correctness 
All of the expressions in the specification must satisfy the type constraints contained in 


the signatures of the abstraction being defined, the signature of the representation algebra, and 


the signatures of the algebras subordinate to either. This means that every operation must be. 
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supplied with the correct number of aigumhiicant fiat be iinien es sack spinon ie 
terminate in only these termination conditions specifind:in:the signature; and produce the right 
number and types of return. values. for. each. This is-not a: purely syntactic check, because it 
may require proving thatthe expression defining. an: dperation: terminates: in a given 


termination condition (usually the normal condition). 
4.4.2 Representation Consistency 


The representation. algebra defined: by.the representation section: must either be a 
member. of the set of algebras generated: by the constructions given ‘eartier: in this chapter, or it 
must have a previously defined standard model. If the representation algebra is defined in 

terms of a parameterized definition, the constraints: specified in the ‘requires: section of the 


parameterized definition musk be met: 
4.4.3 Representation Invariant 


If a restriction on the: principal type ef-the representation algebra is specified in the 
restrictions section, then the range of each operation-defined: must:satisfy the restriction. This 
condition can be established by an inductive argument: assuming that each argument from the 
principal type satisfies the restriction, show that each return value of each operation satisfies the 


restriction. 


4.4.4 Congruence 


If a nontrivial ‘equivalence relation is given in the Identity section, then it is necessary 
4 


to show that each operation is consistent with the equivalence relation; 1 in the sense that it maps 


fy ABS 


“equivatent arguments it into equivalent output This r requirement isa necessary condition for the 
implicit extension of the operations from the representation agera to the c quotient structure to 
be well defined, as ; described below. : eas - a | 

The operations are explicitly defined as functions that operate on:the elements of the 


principal type of the representation.algebra. The model denoted by a eee is in eee 


Bost an. art) atid “wn Fit Ps 
by yet Me Be ae 


a quotient structure, and the interpretations of the Gertions: of the data abariciion in that 
model operate on equivalence classes of elements from the principal.type of the:representation 
algebra. The operations can be extended to eerie on eubyarens ate in the usual fashion: 
If the operation f takes a single argument from the principal type and 5 returns a ‘ingle vale in 


the principal type, then the corresponding operation on equivalence tiasses f_‘is defined: by 
fa( (x) ) = [xD] 


where [x] denotes the equivalence class containing the element x. For: the relatign defined by 
the above equation’ to be single ¥aluedy ‘Snd hence a functiofi ‘on equivalence classes, the 


function f must satisfy the following requirement: ae ee ee riots 


ee ea 


Note that if = is the same as the logical equality relation on the principal type of the 


representation algebra, then this requirement is automatically satisfied. An equivalence relation 


ae 
that satisfies the above constraint is known as a congruence rela “with: respect ne f A 
Mefinition of fe and’ of the es tence requirement, for a rrr ® of an exception 
algebra a Bi sate aCe gts neem: oo | ; 

| Let f be an Operation of the prada 4, If: eee x ey. es Re. where 
Ry =X. X "m(T) and let d be the iain oy type of. A. Aa = ' denote the relation defined by 


the identity section of the specification. Define the equivalence relation | by 


egix, a(x Cd & yO d kx e v(x de At dK xe y) 


bead 
cae 


and define the “equivalence class” ec by 
ectx) = if x « d the fxl ebex. 
H Alxy ....%_)= (7, Cop Integy ) Ds then fer is defined by 


S=Aeckx)), .. » ectx,,)) = <1, < eck), .. » OCF uit) > > ; 


and f must satisfy the requirement 


ese 


Ve : fsaEn[ Oe) ye> 5p eset ae eo ae 


ai 


4.4.5 Termination 


Every operation must be shown to terminate in one of the termination conditions 
specified in the signature for any set of arguments of the proper type, given that any arguments 
from the principal type satisfy the restriction given in the restrictions section of the 


specification. 
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5. Correctness of Implementation 


Every well formed implementation of a data abstraction defines an implementation 
model for the data abstraction. The construction of the bnaienentstion model is discussed in 
Section 51 below. Our basi¢ definition of correctness is that the implementation model must be 
behaviorally equivalent to the standard modet of the abstraction to be implemented. This 
definition corresponds to the- intuition that there shiouft be no observable difference between 
the behavior of the implementation and the behavior’ of ‘the standatd model, cast into the 
framework ‘of deterministic sequential cémputations. — EE 

"The classical way to prove the correctness of an’ implementation with respect to an 
abstract madelsspecifications is to exhibit a horeomerphism: “tn Section 52, we show that the 
classical approach: is::soundiftehe iandard: model’ and the -dinpilementation model are both 
exception: algebras, by.showing that the existence of'a homeltiot phisit Fidtn ‘the implementation 
model tothe standard model implies that'the two models dre béHiaviorally equivatent. “It was 
shown in Section 33.1 that the classical approach is also comptete for the static case, ‘in the 
following: sense: if the standard medet is reduced; ther ‘there extés“a homomorphism from any 
behaviorally equivalent implementation modet to the standard model. 

Section 5.3 discusses the case where the standatd ‘model is an exception algebra and 
the implementation model ,is a state machine. It is shown’ that a correspondence function 
analogous to. a homomorphism can. be used to demoristrate behavioral equivalence. | 

Section 5.4 discusses the case where the’ standard modet and the imptementation model 
are both state machines, In this case there is no useful analog to the ‘homomorphism theorem 


of Section 5.2, and proofs of correctness rest directly on the,definition of behavioral equivalence. 
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The proof methodology is illustrated by examples. 


5.1 Implementation ‘Models 


Ae ae 


An implementation of a data abstraction d supplies a representation for the principal 
type, and an algorithm for computing each of the.operations.:. it. a relatively easy to: construct a 
model of the abstraction from an implementation; if the representation abstraction and all of the 
subordinate abstractions have. been defined:by abstract model specifications. 

The principal type. of the implementation .ayadel. is the reachable’ subset -of the 
principal type of the standard model fer the representation abstsaction. |The reachable subset 
contains just the elements of the principal type that)iate computable by some! finite (closed) 
computation in terms af the operations of. d and. the abstractions: subordinate to d. The 
Interpretation of an_aperation pf the principal sype is the fueation coniputid: by'the proctdare 
implementing _ that operation. . The. principal, type :and-.eperations. of. exch. abstraction 
subordinate to d are taken from the standard model of the subordinate alistraction. 

_ The implementation model iscomplete-by construction, since it contains interpretations 
for all subordinate abstractions. The implementation model many -onenay-net-be reduted. The 
construction guarantees that every object pf the priecipal:type.ef the ianpleinertation’ model is 
reachable. There is no. explicit equivalence class structure in: the. implementation model, so‘that 
several distinct. implementation. objects may represent . the same abstract © object. ~ The 
| implementation model is reduced. if and only if each-abstrat object-has-a unique representation 


in the implementation model. 
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5.2 Static Specification, Static Implementation 


_ The classical method for demonstrating: the cofrettness of an implementation -with 
respect to a standard model specification is to establish a homomorphism from the 
implementation ede) to the standard. model. « in‘ this ¥ection we presenta theorem that 
Geinonstrates that the chaseical method is sound rer cases wnere see the areas model pang 


the inaieineuaden trowel are except algebras. : - eae 
5.2.1 Homomorphism Theorem 


Since an exception ‘algebra ‘has. a disjoint ‘utiton structure not present in the 
fickeroehecun algebras of [I]; we have to extend ‘the definition of a homomorphism ‘slightly. A 
homomorphism between two exception algebras ‘miist (preserva éach’ operation, which means 
that the termination conditions -of corresponding operation itivocations‘ must ‘be ‘the same, and 
that Corresponding fete values: mast be" homomorphic images, whenéver corresponding 
arguments are Wemomorphic images: More: precisely, if A-and’'B ate two exception algebras 
with the same signature, then a hombmorphitiin’ A from: AO! Bi a family of functions 
ha : As phyla, — B. phyla... where a € A. typenames; with the:foflowing property. 


Let P= A. ahiyls F = A. operations, 6 ¢ Picsksinn ne Avaogengt), 
let a; = A. argtype(G; t) and x; ¢-P, , for each / in the raniget's ton, 


let (T, Cy. Im = Fatep ey 
where T ¢ A. tc(B), m = A. rlength(7, 6), 
and where 7 yrds rtype(T, 6, #) andy; € Pr for each:j in the range 12 f Sm. 


Let G = B. operations. 


_ Then Cplhg (xp. ge hag n)) = CT, ¢ hy vo Ay (Im) >». 
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The “=" in the conclusion refers to the equality relation on abstract objects. For models defined 
‘using the specification language introduced in. Chapter.4, this relation is given in the Identity 
section of the specification. 
Now we can. state the homomerphism theorem. 
Theorem 7: Let Ml and M2 be complete exception algebra models with a common signature. 
If there is a homomorphism from M1 to M2 whith: redeem, te: the istentity mapping: on: the 
subordinate types, then Mi and M2 are behaviorally equivalent. 


Proof : By induction on the length of the computation... Details im- Appendix Hl... ; 
End of Proof 


The existence of a homomorphism indicates that the interpretation of any closed 
computation C in Ml is a step by step. simulation, ef the. interpretation of C in M2. 
Corresponding results (data objects) may have different representations in the: two. models, but 
they must have the same properties. Since. the homomorphisen se,required. to re: the identity 
mapping. on the booleans, the. | 


norphism: property. will: guaraatee that any primitive 
predicate will. give the same truth value for corresponding data. sbjens.in Mi and M2... 

_ Note that we are dealing with. complete cpodels, which comtainthe operations of every 
type subordinate to the principal. type-in. addition to the operations of the principaktype. A 
homomorphism must eerste all of the le biace of an fei pad algebra, mewaine those 
associated with the subordinate types. It is sufficient, a consider only ae gethilons of 
. the principal type when proving the correctness of a vatic _enplementation, because the 
component of the homomorphism for each: of the subordinate eypes. is’the- identity foiction, 
which trivially preserves all of the operations of the defining abstraction of each ‘subordinate 
type. The requirement that the homomorpiaism must reduce to the’ ideritity mapping on ‘the 


subordinate types is no restriction in practice, because of the way in which the standard model 
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and the implementation model are constructed. In both cases the interpretations of the objects 
and operations of the subordinate types are taken from the standard models of the defining 
abstractions of the subordinate types. Consequently, the subordinate types have identical 


interpretations in both models, and the natural correspondence between the two is the identity 


mapping. 
5.3 Static Specification, Dynamic Implementation 


In the case where the implementation algebra is a state machine and the standard 
model is an exception algebra, a correspondence function can be used to establish the 
behavioral equivalence of the two models in a way entirely analogous to the homomorphisms 
used in the case where both models are exception algebras. In the rest of this section we present 
a theorem justifying the use of correspondence functions, and an example to illustrate the 
procedure for establishing the correctness of a dynamic implementation for a static data 
abstraction. 

The correspondence function that is used to demonstrate the behavioral equivalence of 
a dynamic model and a static model is not a homomorphism on algebras, even though it must 
have similar properties. Some of the differences between homomorphisms and correspondence 
functions are outlined below. 

Recall that a homomorphism is a family of mappings, one for each phylum. Each 
mapping is a function from a phylum of one algebra to the corresponding phylum of the other 
algebra. The abstract object represented by some implementation object must be completely 
determined by ihe identity of the implementation object, since the mapping takes no other 


arguments. This works well in the static case. In a state machine model, the properties of a 
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data object will depend not only on the identity of the ee but also on the current sig 
state. Consequently a correspondence function must differ from : a homomorphism by taking the 
system state as‘an extra argument. | . | | 

Recall that the principal type of a state machine contains tokens ieoresenting all of the 
data objects that can ever be created. In each system state the population of objects that have 
been created so far is the subset of the principal type.with a proper data state, while the objects 
that have not been created yet are all mapped into the Smpeoper? data state undefined by the 
system state function. In system states where a given token has the data state undefined, the 
token does not represent any abstract data object, and after an | operation | is ® performed that 
assigns a proper data state to the token, the token represents the newly created data object. ‘To 
make the correspondence a total function we adopt the following convention. A correspondence 
function must map a token into the special objet undefined for any stem state for which ch the 
token lies outside the current population. 

The properties of the newly created object are determined at the time the object is 
created, and have no particular relation to the identity of the token representing the object. 
Different computations can lead to states in which a given ek has different properties, sndite 
such a case the correspondence function must map the token into different abstract objects in 
the two states. | 

The correspondence between the tokens of the onicenction model and the abstract 
objects of the standard model is established bya series of approximations, corresponding to the: 
Steps in the computation that create new objects of the principal type. Initially, the sepasistian 
of the implementation model is empty, and the initial correspondence is erngey ie in the initial 


state the correspondence maps every token into the improper object undefined). As new 


— 
objects are created, the image of the token representing the newly coe or changes. from 
undefined in the state just before the object was eeaiad to the abstract object represented by 
the newly created implementation object in the state just after it was created. For abstractions 
that do not attow the explicit‘destruction of data objects, the correspondence functions for the 
“sequence of system states produced by a closed ‘éomputation’ ate a Sértesof pure extensions. If ’ 
0; Yrepresents the state produced: by. the i-th ‘step“of someclésed computation, ¢ is a 


correspondence function, and i < f, then it must be the case that 
(x, O;) * undefined = c(x,0;) = cx, 0 > 


We will refer to this as-the ssondiontity' probe for cerresponderice functions. Once an 
implementation object has been created, and it has. come to. represent. a proper abstract object. 
the monotonicity property says that the implementation object must continue to represent the 
same abstract object in all ieee states. This is just piste sould supe if ae Geta an 
implementation object and assign it to a variable, we would ike to assert that the variable will 
continue to denote the same immutable} abstract object as. long as we do not actign a new value 
to the variable. Spontaneous changes in the abstract identity of the value are not acceptable. | 

A correspondence function must petner to the identity mapping on the subordinate 
types, just as for a homomorphism. Note. that. for the subordinate. types the correspondence 
function is independent of the system state. The abstractions we are considering in this section 
have static standard models, so that all of the subordinate. types must: be static, and all.of the 
objects of the subordinate types must therefore exist. in. all, possible system states, in. the 


implementation model as well as in the standard model 


5.3.1 Correspondence Theorem 


__In this subsection. we define correspondence functions precisely, and .we present: a 
theorem supporting their usefulness. Let A be a state. machine and. let B be: an--exception 


algebra such that the signature of 2. is. contained: in. the signature of A. . A. correspondence 


function from A to B is a family of functions ¢,, :.4» phyla,.x A-phyla, —> Bo phyla, where 


a € B.typenames and where s = A. ss is the name of; the phylum of. spate: states for the state 


machine A. A correspondence ¢ must satisfy the following property. 


Let P = A. phyla, F = A. operations, 8 € B. opnames, a = A. arglength(§), 

let a; = A. argtype(f, Q.and x, © Pa, for each  in.the range. LS iS a, - 

leto€ P,, 

Vet, CO I Ig = FAO, xp XQ 

where T ¢ A. t(B),.0".€ Pm = A. clength(t, 8). re ae ve 9d As 
and where rj" A-type? 6. _jand ¥j¢ i oniaw the range <4 me 


Let G = B. ‘operations. 


Then Gpleg (Or xy). eq (0. x_)) = (1, Ce, (0%, Hh +67 (0 Iq) >. 
x€ Py & oC Asstatenames & ocean x0, x} = fo", x}, 
and x ¢ P, & ~ a € A. statenames => (0, x) = 0", x). 


a 


The correspondence property says that the correspondence fiust preserve all of the operations of 


the target algebra. Note that the few state 0° produced by tHe opera eration of the state machine is 


used to determine the correspondente between ‘the resiilts of the Opefation in the state machine 


arid in the exception algebra. A cofrespondence function must sitso satisfy the monotonicity 


‘requirement; as stated ity the fast two clauses. 


A correspondence function is distinguished ‘from a homomorphism since it takes the 


system state as an extra argument, and since it satisfies the monotonicity property specified by 
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the second clause of the conclusion. Since fie ge of the mapping is an exception algebra, 
there is no component of the correspondence function for the hvlen ol of system states. | 

The correspondence theorem assures us that two models are behavioral equivatent 


whenever there is a correspondence function from one. te the other. 


ialzg’ ite 
ele 


Theorem 8: Let Mi be a state machine model and-let M2-be'an-exception algebra model. {ff 
there is a correspondence function from Ml to M2 which reduces to the: ow mapping ¢ on 
the subordinate types, then Af! and M2 are behaviorally equivalest:::°4 


Proof: By induction on the length of the computation. poate in ‘Appendix III. 
End of Proof % 


The proof is very similar to the proof of the ae theorent except that the 
monotonicity property is required to transfer properties of a data object from the state in which 


_ it, was created to the state in which it.is used as an.apgument-te-a subsequent operation. 
5.3.2 Simple Example | 


A very simple example to illustrate a proof: of -the-cerrectness: of a dynamic 
implementation of.a static. data abstractien-ia developed in this-subsection. | We will consider art 
implementation of the intpatr abstraction in-terms of atraya0f integers: Inepairs are immutable 
pairs of integers, such as might .be. used, to represent. rational numbers on:gausstan integers. 
Operations for constructing pairs, and. for.exteacting -the deft and «right: components “are 
provided. The intpair abstraction is. very. sirilar:te-tuplaltight «int, teft: int) An exception 
algebra model for the intpgir abstraction.is shown in-Figure Ht. 

A state machine model{or arrays és shewn.in Figuredé. “Arrays are mutable; and have 
a variable size. It is not possible to create an atray with uninitialized elements. The atrays” 


defined here are a simplified version of CLU arrays, which: have:mere operations: 


Figure 14, Pairs of integers 


type intpair as P 

with create: int x int > P 
left: _ Pp —> int 
right: P — int 


representation P = tupltefleft: int, right: int} : 


restrictions © none 
identity tuplefequat - 


‘operations _—_—_create(x, y)-= (right :-x, left: y) 
ae teft(x) = x. left 
right(x) = x. right 
end intpair . 


An implementation is shown in Figure 16, and the implemefitation model is shown in. 
Figure 17. The derivation of the implementation model from the implementation .. is 
straightforward. The operations of the implementation model are described in the same 
notation as the operations of-the standard model to’avold introdacing ‘a host programming 
language. We claim that it is useful to define the implementation: model in this styte in doing 
practical proofs as well, thus separating: the issues involved in establishing the correspondence 
between two different representations for a data abstraction from the problem of proving that a 
procedure. written in a particular programming language implements ‘a particular function. | 

To prove the correctness of this implementation; we have to'exhibit a mapping ¢ and 
demonstrate that it is indeed a correspondence function. The behavioral equivaterice of the 
standard. model and the implementation ‘mode wifl then follow from the correspondence 
theorem. In order to distinguish the operations of ‘the implementation model from the 


operations of the standard model in the proof, we will prefix the: implementation operations | 


Figure 15. Arrays 


type array[E] as A 


requires E : type 


with 


data states 
restrictions 
identity 


operations 


end array 


create: int—>A 

addh: Axint->A 

addi: Axint—>A 

remh: A —> + (bounds: ) 

reml: A — + (bounds : > 
store: A x int x E — + ( bounds: ) as argi[ arg 2):= arg 3 
fetch: ‘A x int — E+ ( bounds : > as arg!{ arg 2) 
equal: AxA-> boolean — as arg| = arg 2 

low: A — int . 

high: A — int 

length: A > int 


_ D = tupleflow: int, e: sequence[E]}) 


none 
tuplefequal 


create(sXi) = state[D]$extend(s, (low: i, e: © >) 
addh(sXa, x) = (state[D]#update(s, a, (low: s(a)- low, e: s(a).e |+ x)), a? 
addK(sXa, x) = (state[D tupdate(s, a, (low: s(a). low - I, e: x +{ s(a). e)), a) 
remh(sXa) = if #(s(a).e) = O then ( bounds: s ) 
else <state[D }#update(s, a, (low: s(a). low, e: buttast(s(a). e)), a> 
remi(sXa) = if #(s(a).e} = 0 then ¢ bounds: s > 
else <state[D fupdate(s, a, (low: s(a). low + I, e: butfirst(s(a). e)), a> 
store(sXa, i, x) = if s(a). low $ i $ s(a). low «+ a(s(a). e) - I 
then state[D]}#update(s, a, <low: s(a). low, e: s(a). ef. if] |» x +1 s(a)- efisf ..J>) 
else ( bounds : s ) 
fetch(sXa, i) = if s(a). low < i ¥ s(a)s low + #(s(a).e) -} 
then (5s, s(a). ell - low + i] > 
else ( bounds : s > 
equal(syal, a2) = <s, token#equaXKal, a2)) 
low(sXa) = <s, s(a). low) 
high(sXa) = <s, s(a). low + #(s(a). e) - 1) 
length(sXa) = <s, #(s(a). e)) 


with a "1". To help the reader distinguish elements of the standard model from elements of the 


implementation model, variables ranging over implementation objects will also be prefixed with 
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Figure 16. Implementation 
representation = array(int] 


operations create(x, y) = So ee x), mn 
left(p) = fetch(p, 1) 
right(p) = fetch(p, 2) 


Figure 17. implementation Model a ee ee 


representation arraylint) 


operations —_—_create(sXx, y) = addh(s2Xp2,y) 
where {s2, p2) = addh(siXpl, x) 

(sl, pl) = arrayfcreate(s§). .- > 

left(sXp) = fetch(sXp, 1) 

right(sXp) = fetch(sXp, 2) | 
a“ 


The correspondence function for ius exarmple is the following, 
cls, a) = (left: sla). ell]. night: sa)eelQ> 


We have shown only the sioobiponiehs of the crrexpandenc, far the principal type int pair. The 
correspondences for all other types are: identity. functions. i cee 

The proofs for the operations. create and iat are. shown, ‘below... The proof for the 
operation right is similar to the proof for left, and is eft as an cuts for the reader... Fhe. 
proof relies on the implementation invariant I shown below, which is a restriction on the data 


state of every object representing an intpair. 
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Let x, y be integers, 
ta, lp be lintpairs, 
ts, 1s0 be system states for Lintpairs, 


Let Il = is(tp). low = 1 & a{is(Ip).e) = 2 


create 

Let (ds, la) = Icreate(1sOXx, y). 

We have to show that c(Is, Ja) = create(x, y). 

From the definition of create, create(x, y) = (left: x, right: y). 

From the definition of ¢, c(Is, 4a) = Cleft: Is(1a). ell], right: Ls(1a). e[2)). 
Using the definition of tupletequal, we have to show that 

4s(1a). ell] = x and Is(!a). e[2) = y. 

From the definition of the array operations create and addh, 

ds(ta) = (low: I, e: <x, y)) and Is(1p) = Is0(1p) for Ip # Ja, 

so Is(ta). e[I] = x and is(1a). e[2] = y. 

So c(1s, la) = create(x, y). 

Since Ja is newly created and !s(Ip) = 1sQ{ip) for all lp # La, 

the monotonicity property holds. 

Since the array operations create and addh can only terminate in the normal condition, 
¢ preserves the termination condition of the create operation. — 

So ¢ preserves the create operation. 


Also is(la). low = | & a#(!s(la).e) = 2 and Is(!p) = Is Ip) for lp # Ja, 
so that the implementation invariant holds in state Js if it holds in 4s0. 


left 

Let (4s, x) = Heft(1s0, 4a). 

Let a = c(Js, Ja). 

We must show that x = left(a). 

By the definition of c, a = (left: Is(ta). ell], right: ts(ta). ef2)). 
By the definition of left, left(a) = Js(1a). eff]. 

From the invariant, lsQ{la). low = 1 & a(1sO(ta).e) = 2 

so Isla). low <1 < isla). low + #(tsOla).e) - I, 

and by the definition of Left and array#fetch, 1s = 1s0 and 

x = Ilsa). eff - 1 + 1) = dsQX sa). eff]. 

So x = left(a). 

left and Jleft always terminates in the normal condition. 

So the correspondence c preserves the left operation. 

Since Is = 1s0 the monotonicity requirement is trivially satisfied. 
The implementation invariant holds since !s = 10. 


right 
Proof left to the reader. 


- il4- 


For the purposes of comparison, if immutable sequences had been used as the 
representation of int pair instead of arrays, the homomorphism would have been the following 


for the analogous representation: 
A(x) = ¢ left: xff], right: x2] >. 


The proof would have been similar for the immautable. case, except that there would neve been 
no need to show the monotonicity property, and no. need to- argue ‘that the. deta ‘states of 
previously existing data objects satisfy the implementation ination, ‘as ‘we did for the create 
operation. For a mutable implementation, it: is important to include. this pan. of the arguement 
because the implementation. invariant. is 2 constraint.on ane Saaine @ syst state, rather dae just 
on the images under the new system state of the data objects returned, A conretly implemented. 
operation must preserve the invariant, which means that the inyariant must ew with. respect 
to all data objects after the operation is setleemed: “This includes the objects ‘retired by the 
operation, as well as any others whose state may have changed as a resuk of the operation. 

Note that the proof methodology Preen es here has no difficulties handling 
implementations with benevolent side effects. It the correpondence function. .is.: many. $0: one, 
"then an operation may change the state of: an- imphention objet without affecting the 
correctness argument, as long as the image of ike implementation sbiect under the 
correspondence function does not change. Such: side. aii can be. useful in. cases where an 
operation neamange a data structure to make future # operation on that structure more efficient, 


~ without changing the externally observable behavior of the structure. 
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5.4 Dynamic Specification, Dynamic Implementation 


The correctness of a dynamic implementation of a dynamic data abstraction can be 
proved by constructing a simulation relation, and by showing that the simulation relation holds 
for all closed computations. The method of simulation relations is a general solution to the 
problem of proving the behavioral equivalence of two models, since it can be applied to both 
Static and dynamic models. If the standard model is static, then some simplifications are 
possible, as illustrated by the homomorphism theorem and the correspondence theorem 
presented in the previous sections. In this section we consider the fully dynamic case, where the 
full power of simulation relations is needed. 

Recall that each object of a dynamic type is modeled by a token. Tokens have no 
distinguishing features other than their identities. The properties of a data object represented 
by a token are modeled by the images of the token under the current system state function. To 
establish the behavioral equivalence of two models, we must specify the correspondence between 
the tokens of the two models, and also the relations that must hold between the states of 
corresponding tokens. The first of the two correspondences is the correspondence relation + 
described below, and the second is described by the simulation relation. For a pair of state 
machine models, the simulation relation is typically defined in terms of the correspondence 
relation. 

Since tokens do not have any distinguishing properties other than their identities, it is 
generally not possible to describe the correspondence between the tokens of the implementation 
model and the tokens of the standard model without reference to the computation that produced 


the current state. The correspondence relation for tokens is easy to describe in terms of the 


eae: 
computation, since the results of corresponding steps of the sass in the two models nue 
correspond to each other. The correspondence relation is defined more precisely.as follows. 
Definition 20 Correspondence Relation 

If the computation C is feasible in models Mi and M2, if x.is the ith return value of 

the jth step of the interpretation of C in MI, and if 7 is the i-th return value of the 

J th step of the interpretation of C in M2, then we will saythat:x. corresponds toy 

and we will write x # y, 
The correspondence relation applies to system states as well as to data objec. | The 
correspondence relation is syntactic in nature: it is “defined | in terms : of the structure of the 
computation, without any regard for the meanings of the \iiauiions s0 that the same definition 
applies to all data abstractions. —_ 

The simulation relation describes the retation that must hod between the states of 
corresponding data objects in the two models for the objects to lave the same + externally 
observable behavior. ras of simulation relations can be found in the proc of correctness 
given in’ the following sections. ea ed : | 

A typical proof of correctness proceeds by induction ¢ on the length of the computation, 
to show that for any closed compuiation, the termination condition of the last step is ane same in 
both models, and that the simulation relation holds in ‘the final states of the | two models. The 
_ proof splits up into cases on the type of the last operation. of the computation, with one case for ; 
each primitive operation. ca 

To establish behavioral equivalence, the simulation relation must imply that 
corresponding: boolean values are equal. “Typically the simulation relation will be the | 
eonieiatton of a number of clauses, where each clause is an n implication. The hypothesis of the | 


implication’ says that a number of pairs of objects have given types afd: are related by the: 
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correspondence relation #. The conclusion describes the relations that must hold between the 


identities and states of corresponding objects. The clause stating the standard requirement on 


boolean values is the following: 
bo lb = b = Ib, 


where we follow the convention that variables prefixed by a "!” refer to elements of the 
implementation model, while variables without such a prefix refer to elements of the standard 
model. Just as we required the homomorphism or correspondence function used in a proof of 
correctness of a static data abstraction to be the identity mapping on the subordinate types, we 
will in general tequite a clause in the simulation relation for each subordinate type, stating that 
corresponding objects of the subordinate type must be equal. 

In order for the induction to go through, the simulation relation must be strong 
enough to enable the simulation relation to be proved in the final state, given that the 
simulation relation holds in ail previous states. In working out sample proofs, we have found 
that the definition of the simulation relation usually evolves along with the proof. In the 
beginning, the simulation relation states just the required constraints on the boolean domain 
and on the other subordinate types. In considering each operation, it is often found that an 
additional hypothesis is required to show that the operation preserves the simulation relation 
defined so far. As clauses are added to the simulation relation, it is of course necessary to go 
back and show that the other operations preserve the new clause as well. If the implementation 
is in fact correct, then this process will eventually terminate in a proof that every operation 
steeeves every clause of the simulation relation. 


The use of the correspondence function « is one difference between proofs of 
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correctness for dynamic abstractions and for static abstractions. Another phenomenon that 

occurs only for dynamic abstractions is that sometimes it is necessary to consider the ‘operations: 

of the subordinate types in the correctness proof, as well as the opérations ‘of the principal type. 

The operations of any mutable subordinate type must be considered, since they can modify the: 

system state, and since the simulation relation (usually) depends on the geste state.’ The 

operations of static subordinate types need’ not ‘be ‘considered, ‘because they cannot change the 
| systen) state or return objects of the principal type: Since ali of the subordinate » types of a static 
abstrattion are static, the Gpefations of the subordinate types of any ‘tatié abstraction need not 

explicitty enter into the correctriess proof. ee et 

" Aly ittteractions between the observable behavior of a mutable data abstraction and 

the operations of its mutable subordinaté types depend ‘on the ‘mutation of shared data objects. 

Sitice ‘the suboriiate retition’ on ‘models is a ‘well founded pri order, 1s not possible for 

any of the opérations of a subordinate type to operate ‘directly ‘on any y objet of the principal 

type. It’is possible’ for an object x of'a subordinate type to stiare some ‘substructure with an | 

object 9 of the principat fype, so that the externally observable behavior of ycan depend on the 

state of x. Sharing of this kind can occut'by contruction’ or by decomposition. In the first case, 

some primitive Gperation ‘takes’ x as ah afgunient and incorporites it into 9, where tithes S is 

passed as an atgument to the operation or created by the operation and rolumed. Inthe second 

case, some primitive Operation takes yas an atgumént and returns the component x. a 

‘ For an’ example ‘of a case where ah interaction’ with the operations of a suibordinate. 

type is possible, consider the msef abstraction described ai follows. ‘Mets are mutable sets, with 

the usual set operations, and also an elements operation that returns an array ‘containing the: 


elements of the’ set. In the'stindard model, the elements operation returns a newly created array, 
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without affecting the state of any mset. Consequently, a subsequent assignment to some element 
of the array returned by the e/ements operation does not shies the contents of the mset from 
which the array was derived. An implementation in which such an assignment did affect the 
contents of the mset would not be behaviorally equivalent to the standard model, but the only 
way to detect the difference is to perform an array$store operation, which is an operation of a 
mibtable type subordinate to mset. (Such an incorrect implementation of mset is plausible, | 
since it would arise if the programmer chose to represent msets as arrays, and in implementing 
the elements operation forgot to return a. copy of the array representing the mset, rather than 
the representation itself.) For such an incorrect implementation, it would not be possible to 
prove that the array#store operation preserves the simulation relation, even though it could be 


possible to show that every operation of the principal type does preserve the simulation relation. 
5.4.1 Simple Example 


In this section we present a proof of correctness of an implementation of the unique_id 
abstraction. This is just about the simplest possible data abstraction that requires a state 
machine model. Recall that unigue_ids are immutable, but they can be dynamically created. 
The standard model for the unique_id abstraction is repeated for the reader's convenience in 
Figure 18. An implementation of unique_ids in terms of arrays is shown in Figure 19. In this 
implementation, we are taking advantage of the fact that array§create always returns a new 
array (one that has not been used yet in the current computation). The implementation 
depends only on the identity of the array, so that the contents of the array can be changed 
arbitrarily without affecting the correctness of the implementation. A newly created array has a 


length equal to zero, and a specified lower bound for the indices. The standard model for 
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Figure 18. Standard Model for Unique_id 


type anique_id) asU 


with treate: -~>U 
equal: U x U — boolean 
data states D-= ( null } 
operations create(sX) = extend(s, null) 
e 8  eqtsh2 ECs, v > 
where V = if tokenfequakx, y) then true else false 


end unique_id 


mane 19. peerenentevon of Unique_id 
representatoy: “aareyiint) 


operations create() = snail 
equakx, y) = arraylintWequaKx, y) 


arrays is shown in Figare {5-in Section 532. ‘The proof of correctness is shown below. As 


before, we will prefix operations, object s, and ‘states bélotig ing to the imptemen mentation with a 7° 
to distinguish them from their counterparts th the standard médel. - 


To prove that unique_id and ieee’ id are behaviorally equivalent. 

Proof by indtiction on thé fength of thie computation: ° 

Assuming the simulation relation R holds for all Comperation’ Cc such that 1 < S length(C) <.N, 
strow that R holds -for-all © stictt that tengthtC) N. . 


Let s, 80, sl be system ‘states for unique: id, - 
ds, 450, Isl be system. states for ao Jd, 
x, xl, y, 2 be unigte_ids 
dx, Ixl, Ly, lz be unique ids 
‘b, $b be booleafis. 


Let R =x 0 {x & § o Is => used{x, 8) = used(!x, 4s) 
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& xo lx & yo ly = (x = y) = (Ix = Ly) 
& bo lb = b= Ib 


Proof by cases on the name of the last operation in C. 
Case I: create 


Let sO « 1s0. 

Let unique_id$create(sOX) = (sl, x1) and lunique_idfcreate(!sOX) = (Isl, Ixb, 
so that si « fsl and xl Ixb 

By the definition of unique_idfcreate, statefextend, and statefused, 
used(xl, st) & — used{x1, sO) 

and used(z, sO) = used(z, sl) for z # xb. 

By the definition of array§create, statefextend, and state$used, 
used(Lx1, Isl) & — used(Ixl, 180) 

and used(lLz, 1s0) = used(!z, Ls!) for lz # Ixl. 

So z 4 Iz => used(z, sl) = used(!z, dsl) for any z, 12. 

So the first clause of R is established for sl, Isl. 


- (lemma 1) if z # xland ze tz then lz # Uxk 
used(1xi, Isl) & > used(Lxi, 150), 
but used(1z, Isl) = used(z, sl) = used(z, s0) = used(1z, 480), 
So Iz # IUxl. 


(lemma 2) if z = xl and z 4 Jz then dz = Uxt: 
Since z = x1, used(z, sl) & 7 used(z, sO). 
By the first clause of R, used(1z, Isl) & — used(tz, sO). 
used(1z, 1s0) = used(!z, si) for lz # Uxl. 
So lz = Ixl. 


Let x e lx and y # ly. 
Case Il: x # xl, y # xl 
By lemma I, x # Ixl and ly # Lyl. 
So xo Jx and y 4 Ly in the prefix of the computation C. 
So the second clause of R holds by the induction hypothesis. 
Case 1.2: x = xl, y # xl 
Then x # y. 
By lemma 1, ly # Ixt. 


By lemma 2, !x = Uxl. 
So Ix # ly and the second clause of R holds. 
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Case 1.3: x * xl, y = x! 
Similar to Case 1.2. 
Case 1.4:x = xh y = xl 
Then x = y. 
By lerwma 2, 4x = xl = ly,. 
So the second clause of R holds. 
The third clause of R holds since create and tcreate pe not return any boolean values. 
So R holds. 
Both create and Icreate always terminate in the said condicion: 
Case 2: equal 
Let s0 @ Js0, x0 «+ 1x0, and yO + Ly0. 
Let equaKs0Xx0, y0) = (sl, b) and lequaK!s0X1x0, ty0) « . st, 1b). 
By the definition of equal, sl = sO and b = (x0.= yO)... 
By the definition of lequal, Isl = 1s0 and Ub = (1x0 = 4yQ) ger et 
Since R hokds in sO, (x0 = 90) = (1x0 470), so:-b.=. Jb, aod R holds, : 
Both equal and lequal always terminate in the normal condition. 
So + preserves termination conditions and truth values. . 
Therefore unique_id and ae as are eee ivan 
The most important property of a unique_id. is that it is unique. This js expressed by 
the second clause of the simulation relation R, which says that two unique id's have the same 
representation if and only if the abstract objects they represent are identically the same. The 
third clause of R is just the standard requirement on. baolean.values, from which. the behavioral 
equivalence of the two models follows easily.. The only operation of. uniqueid.that produces a 
boolean value is equal, and for that case the third clause of R follows easily from the second 
clause and the definition of equal. Establishing the second clause is harder, requiring the 


addition of the first clause to the simulation relation, to strengthen the. induction. hypothesis. 


The first clause is based on that fact that corresponding objects in ‘the implementation and in 
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the standard model are created at the same time, so that either both exist (in states after the 
abstract object has been created) or both do not exist (in states before the abstract object has 
been created). Since the object returned by unique_idfcreate is always newly created (and hence 
distinct from previously existing objects), and since only one object at a time is created, the 
unique representation property is preserved. 

The proof shown above is a typical example of the argument used to establish a 
unique representation property, treated in detail. Similar properties will be required in later 
examples, and we will sketch the proofs without filling in all of the details, assuming that the 


reader can adapt the argument given in this section. 
5.4.2 Typical Example 


A simple example of a proof of correctness for a dynamic data abstraction is presented 
in this section. We have adapted the intset example from [18], without incorporating the bound 


| A standard model for intsets is shown in Figure 20. Intsets are mutable 


on the size of a set. 
sets of integers. The empty operation creates a new intset, which is initially empty. The insert 
Operation inserts a given integer into a given intset, returning no values and changing the state 
of the jntset. The remove operation removes a given integer from a given intset. The Aas 


operation tests to see if a given integer is a member of a given intset. 


An implementation of intsets in terms of arrays is shown in Figure 21. This 


1. If sets with a bounded size are desired, then an exception conditions should be associated 
with the insert operation to indicate when an attempt has been made to exceed the size bound. 
This will add another case to the proof without further illuminating the methodology, and 
hence is omitted. 
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Figure 20. Standard Model for Intset 


type intset as TF 


with empty: >I 
; insert: I x int > 

remove: Ixint— =~) 
has: I x int — boolean | 

data states D = setfint) | 

restrictions = none — 

identity setfequal 

operations empty(sX) = extend(s, set#nulK)) 


insert(sXx, i) = updatefs, set¥add(i, s(x))) 
remove(sXx, !) » update(s, set$remove(i, x(x) 
has(sXx, i) = <s, set#member(i, s(x))) 


end intset 


Figure 21. intset Implementation 


representation _ intset = arraylint) aa - é 
restrictions a such that lowa) = 1'& ( lowla) < j,k < highla) & j # k => a(j) # a(k)) 
identity . arrayfequal 


operations empty() = ee 
- insert(a, i) = if  has(a, i) then addhla, i) 
remove(a, i) = if has(a, i) then { store(a, find(a, i), alhigh(a)) ; remh(a) } . 
has(a, i) = if Jjllow(a) < j $ high(a) & alj-i) then true else false 
definition | find(a, i) = if Ajf aff} = i] then j : ali) = i else 0 


implementation keeps at most one instance of. any. given integer_in an array, but the order of 
the elements is arbitrary. The standard model for arrays is shown in Figure {5 in Section 5.3.2. 


The proof of correctness is shown below. An explanation follows the proof. 
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To show that intset and Jintset are behaviorally equivalent. 

Proof by induction on the length of the computation: 

Assuming R & II for all computations C such that 1 $ lengeh(C) < N, 
show R & I for all C such that length(C) = N. 


Let 


s, SO, si be system states for intset 

Js, Is0, Js] be system states for lintset 
x, xl, z be intsets 

Lx, Lxl, 4z be Jintsets 

i, il, Li, Lil, k, n be integers 

b, bl, !b, {bl be booleans 


LetR = Isos&Ixox& die i => (i € s(x) = All $j < o(Ls(tx).e) & di = Is(tx). efj] ) 


&lbeb= Ilb=b 


Let I = §s(tx).low = 1& (1S j,k S #(Js(Lx)ee) & j # k => Is(Lx). efj] # Ls(tx). elk} ) 


R is the simulation relation and I is the implementation invariant. 


Proof by cases on the name of the last operation of C. 


Case I: create 


Case 


Let 1s0 © 50, Icreate(isOX) = (isl, LxP, create(sOX) = <sl, xD 

Then we have Js! sl and Ixl © xl 

By the definition of create, si(z) = sz) for z # xl 

By the definition of create, Jsi(1z) = lsO{Jz) for lz # Lx! 

So R and I hold for s = sl, ds = dsl, x # xt, Lx # Ex 

For x = xl and Ix = Ixl we have 

sl(xl) = set#null{), so i € si(xi) is false for all i. 

dsI(Lx1) = (low: I, e: O), #(Js(1x). e) = 0, and I< j $ 0 is false for all i. 
So R holds for the pair of states sl, Isl. 

isl(Lxl). low = 1 and 1 < j,k $ 0 is false, so I holds. 

© preserves termination conditions since both create and Icreate always 
terminate in the normal condition. 


2: insert 


Let s0 6 Js0, xl 6 Exi, Heo Lib 

Let insert(sO)xt, il) = sl, dinsert(dsOX1xl, Jil) = Isl. 

Then sl 4 Isl. 

We have s0(z) = siz) for z # xl, and similarly for 1s0, 

so we have to show R and I only for x = xl, lx = Lx], = si, ds = Ist. 
By the definition of insert, si(xl) = sQ(xl) U { il }. 


. 126 - 
Case 2.1: if ¢ sOXx!). 


Then six!) = sO(x!), sed “hence sh=sQ, . 

Since R holds in s0, Ijfl < j < e(1sO(tx!). e) & ata - =u 
So Isl = Js0 by the ioneien of linsert. “ 

So R and I hold by the induction hypothesis... 


Case 2.2: > if ¢ s&x!). 


From R in s0, > fl < j < o(bsO(Ixl). €) & IsO(txl). fj} = dil) 
From the definition of Jinsert, tsI({x1) = Cow: I, e: IsQ dx). € I $id. 
ee $js o(}sXIxI). 2) Be ASO x1. ef] x. die : 
i<js < a(Isi{Ixt). e) - 1 & Isi(txt). efj) = sil) 
i IskK tx). efj) = Ji for j = ERY: e), 
, $0.R holds in st, Ist. sie 
From the definition of Linsert, Is(Ix). iow =I. 
KE holds for 1 $ j,k &. . a(ts0fLxl).-¢) = ofa tal).e) = I by the induction hypothesis, 
and I holds for 1 <j < k = o(IsKIxi).e), 
since ~ Ajfl < j < #(1sO(UxI). €) & deQXbudv-elj) + Si 
So I holds. 
# preserves termination conditions since both insert and linsert 
always terminate in the normal condition. 


Case 3: remove 


Let sO © Js0, xb @ Ixl, ilo Sib, : 

Let removefsOXxI, il) = sl, removed OK 1d) « Isl. 

Then sl o Isl. 

We have s({z) = si(z) fats z * xi, and simitarly. aie See 
s6 we have to show Rand. Hon for 3 wha = as dsedst 
By the definition of remove, sx!) = sO(xi) - { ae Pes AE 


Case 3.1: il © sOQ(xl) 


Since R holds in s0, 450 , Ail $ j < o(sO(Ix1)s e) & 4s0(xt)» eff) = Lif] 
Choose n such that 1S n < o(1sQX1xi). e) & IsXKixl). efn} = Jil. 
I holds in s0 so n is unique and n = find(JsOXExi, 441). 


Case 3.1.1: n = e(lsQ$x!). e) 


Then from the definition of .Jremove,. - 
IskIx1) = Clow: I, e: IsQ(Lxt). ell.n-1)). 

From If with k = n and the previous.tine, 
— Aj $< jS o(1sK tx). e) & Ist{Sxi). efj) = Lil], 
so R holds for i = il. 
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Since Isi(tx1). e{k) = 1s0(1x1). elk] for! <k <n, 
‘ for i = il, Aff <j < #(1s0(Ix1). e) & Is0(tx1). efj).- -ti)= 
© HES j < o(tst(txd) e) & sacten, dj- ‘W, . 
So R is established in si, sl. oe 
I in {sl follows from I in 450. 


~ Case 312: n = o(lsO(Ixt). 6) 


Then from the definition of lremove, ~~ * 
— Ust(Lxl) = Gow: 1, e: ql. nl] + qeq) ‘| qinel. aq). 
* where q« tsXIxt)ce. 
From I with k =n and the previous line, . 
~All <j < a(tsH(dxt). &) & Isi{Uxt). eli) = un 
so R holds for i = il. 
Since Ish Ext). ek] = IsQXIxl). thitor fk <in-1 and neilskés eq - 1 
and Isi{1xi). elm) = LsOQ{(txi). eleq], | . 
‘fori # il, 30 <j alisKlxDee e) & 130(4x!). ej) = ti) = 
Ail < j < o(ts(txi). e) & Is{txl). eff] ti) 
So R is established in sI, tsi. 
. Hin Isl fotlows from I in 450. 


Case 3.2: — jc sx!) 


Then sKxl) = sO(x!) - { il} = = SX(xl) so sl = sO. 
Since’R holds in 80, ~ All <j < ‘a(LsOCixt). &) & IsOKixf). ej = till, 
so Isl = 130, by the definition a lremove and thas. 
So R and I hold in si, Isl. 
+ preserves termination conditions since both remove and tremove. 
always terminate ih the normal condition. 


' Case 4: has 


Let 20 © 150, xl 6 tx, jlo dil. 

Let has(sOXx1, il) = (sl, bi), thas(1sOXtxi, ul) = ast, Yb). 
Then'st 4 fstand bre th 

From the definitions of has and thas, sl = 0 and isl = » 430, 

$0 FE holds. | 

We need to show that bi = JbI. — 

By thé definition’ of has" bl = it ¢ sital). ae = 
By the definition of Jhas, dbl = Ait <j : ots txt). e) & 04tx). be ui) 
By the first clause of R; bf = tbl: 

+ preserves termination conditions since both has and thas always: 
terminate in the normal coridition. . 


Since © preserves termination conditions and the simulation relation, — 
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all computations are equifeasible in intset and in. hintset, and each | Gd 
computation producing a boolean value produces the same value ie both models. 
So intset and Jintset are behaviorally. equivalent. Goes es 


The only primitive intset operation that can produce a boolean. value is Aas, and the 


relationship required for the has operation to give the same. results in beth, odes is expressed 


by the first clause of the simulation retation R. The in invariant I expresses a 


restriction on the implementation structures, that must be maintained by ‘the operations of the 
implementation: Note that the implementation invariant does not. mention ‘any objects of the 
standard model, in contrast to the simulation ‘telation, which. ts pooceened, with the relations 
between the two models. The limplementation invaciant ‘Says, that all of the elements of the 
array representing an intset must be distinct, and ‘that the tow bound of the array must be 
always equal to I (recaff that arrays can grow and shrink from both ends). The implementation 
invariant is needed, in. the prook to. show that the ea rein eroere he simulation 
Whenever there is a state transition caused by the inveration of an operation of the | 
State machine, we have to reestablish that the properties required for our proof of correctness 
are still true in the final state. There can be no a seneres nate for berate pEeperties 
from one state to the next, becuse there is no + ogi syntactic. relation. between. the text 
specifying an openition and the set of data objects that can be affected by the nperation. In 
general, the effects of an Speation are not Hirnitey to the data soba. that. are. passed as 
arguments to the operation, because the data state of an abject can, contain other data. objects, 
which in turn can have data states containing still more data objerts. An invocation of an 


operation can potentially affect. every object in the reachability closure of the arguments, which 
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can vary from one state to the next. Consequently we must establish the invariance of 
properties of data objects with respect to state transitions on a case by case basis. 

As can be seen in the proof above, explicitly arguing that each property is transferred 
from one state to the next need not lead to unmanageable complexity. In a correctness rbot we 
are typically trying to show that the simulation relation and the implementation invariant 
remain true in spite of any state transitions that may be caused by the operations of the data 
abstraction we are trying to verify. In the example above, the arguments are very simple, since 
there is no potential for data sharing between intsets. In the example shown in the next section, 
there is potential sharing among the objects of the principal type, so that the arguments 
required to show that the simulation relation is preserved by a state transition have more 


content. 
5.4.3 Sophisticated Example 


A sophisticated example, consisting of the nonstandard implementation for mutable 
lists discussed at the end of Chapter 3, is presented in this section. This example treats a 
mutable abstraction whose objects may share subcomponents. The implementation is not 
reduced, so that more than one object (token) in the implementation may represent the same 
abstract mutable list. The standard model for mutable lists is shown in Figure 22. The 
implementation model for mutable lists is shown in Figure 23. We have defined the 
implementation model in the same notation as the standard model in order to keep the example 
as simple as possible. Strictly speaking, this example shows a proof of the behavioral 
equivalence of two models. The proof of correctness is outlined below. The proof for the cdr 


operation is very similar to the proof of the car operation, and similarly for rplaca and rplacd, 
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Figure 22. Standard Model for Mutable Lists 


type list as L 


with 


data states 


restrictions | 


identity 


operations 


end list 


nil: . aS L 


cons; LxboL 

car: kL + (no_car: ) 
dt Lbs (Caner: - 
rplaca LxL->L-(no_car: > 
rplacd:| 2 LK LL (nodes) - 
eq: L x L — boolean | 

D- oneof{null: to pa: toptt L, i: un 
none... : 
tokenfequal 


niKsX) = state[D#extend(s, nil in null) 
cons(sXx, y) = satel Bextend(s,-: x, 1: yin pair) 
car(sXx) = if is{pairXs(x)) then (s, tolpairXs(x)). 1) 
else (no_car : s) 
cdr(sXx) = a is(pairXs(x)) then <s, tolpairXs(x)). De 
else (nos cdr : a 
rplaca(sXx, y) = if islpairXs(x))  fecacee’ ar : 
then GtatelD Bupdatets, x, ey y r: - tolpairdsty))e Di in eel ») 
else (no_car: s) 
rplacd(sXx, y)- «if islpair etx). 
then at update, x c dpa ir: ep in il x) 
- Che oredr) 2 6 oy 
elas y) . wie ie aa ” 


so that only one proof.is given. for each pair of operations, and: the other. ts left.to the:reader. 


An explanation is given after the text of the: proof, 


To show that list and Jlist are behaviorally equivalent, 

Proof. by induction an.the length of the. 

Assuming R holds for all computations C such that IS <lengtic) < < N, 
show that R holds for all.C such that lengthi(C)=N. > 


Let 


sO, st be system states for list, 


ds, 150, Isl be system states for List, 
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Figure 23. Implementation Model for Mutable Lists ~ 
data states D = cellfoneof(null: { nil }, pair: tupiell: L, it LO 


operations niksX) = sarcaenenitha biel iil) ih niu)” 

cons(sXx, y) = statellist extend (statef ea ente ak tt x, f p in pan. 
car(sXx) = if islpairXs(s(x))y 

then (s, tolpaleKtaini Q- 

else <no‘cat: $¥ 
edr(sKx) = if islpairXs(s(x)) 

© thel’ & tolpair Rit W: i: 

ttse’ hos ‘y° a 
rplaca(sXx, y) = if islpairXs(s(x)) 

then state[list Bextend( 
state(ceti fupdate( 
2 ; eh (t as tah 1 in pair ). ‘ 


else bo car: 8) 


tplacd(sXx, y= slog Bees 


aa. on if cy) in dite). 


w, x, y, 2, x0, yO be lists 

lw, lx, ly, dz, 1x0, Ly0 be Jists, 
b, tb be booleans, 

dc be a cell. 


Let RE(xedx& so bs & isfnutlXs(x)) => islewuNXtsttstix)) ) 
&(xelxkseolsk eae => see 7 

. AM ).te aise): ¢) ; 
B (note ey ty hs tome (ey =e neat on 
&(belb=>balby eee | 


Proof by cases on the name of the last operation of C. 
Case f: nil 


Let s0 © 150. 
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Let nil(sOX) = (sl, w) and InikssOX) = (Isl, Jw). 

Then slo tsiandweldw. , to ie ba eae, 
. Siz) = sQXz) for z # w, and ‘similarly for 431. 

rap PMRR A 8 a) aaa a Baga 0% 1 es ie 

By the definition of nik isinuliXnKw))..- ee oe 

By ‘the definition of Inil, isfnullKisi(isKw))). 

So the first clause of R hokds. ' : 

The second clause is trivially true for x = w, 4 = iw 

since the hypothesis of the implication is fale. —. hah 

Since w and JsKJw) are newly created, the thie, fF nie oR holds. 

Both nil and inil always terminate in the slecnianieaal 


date Mi 


Case 2: cons 


Let sO ¢ Js0, x0 + 1x0, ye ty0, 

Let cons(sOXx0, y0) = si,’ w) and tsa, Ho = (sl, bw). 
Then sto Isl and w oe iw. 

si(z) = sO(z) for z * w, and similarly for dat bes : 

So we need to show R only for x, = w, tee. iw. 

By the definition of cons, is{paix (skw aw, | l= 0, and sKw).r = y0. 

By the definition of Jcons, is He si WO, isKisKtw)). | = 1x0, and Isi(isKiw)).r = 1y0. 
The first clause of Ris trivia ; 

Since x0 + 1x0 and yO # Ly0, i second. clause of.R holds. 

Since w and IsK(tw) are newly Created (he posi sur of fhe hokis... 

Both cons and icons always terminate in 


‘Case 3: car 
Let s0 # 380 and x0 + Lx. 


Case 31: islpairXsO(x0)) 
t 
Let car(s0Xx0) = Gt, w) and teartdaOitxOh - sl, 4w). 
Then si + Isl and w o Jw. 
By the definition of cat, sl = $0 and ve = s0(xd). 1. 
. By the definition of. Acar, Ish = $30,apd Iw = 130(1s0(1x0)). | 
Since sl = s0 and Isl » 150, R. holds in si, isl for x, y # w. 
Since R holds in 30, 480, islpairKtsO{4s0(4x0))) and s0(x0)s 1 4. $80(190(1x0))> 
So w « tw for the prefix of C. 
So R holds for si, Isl. oe ge ae 
Both car and Jcar terminate in the normal condition for this case. 


Case 3.2: is[nullKsx0)) 


Then since R holds in s0, is{nullKtsO(JsO!x0))). 
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Let car(sOXx0) = sl and dcar(4sO0Xtx0) = Isl. 

Then sk + Ist 

By the definition of car and tear, i= 50 and re 430, so R holds. 
Both car and Icar terminate in the no _car condition for this case. 


Case ¢: cdr 
Similar to Case 3, proof left to the reader. 
Case 5: rplaca 
Let sO + Js0, x0 + 1x0, and yO « 1y0. 
Case 514: islpairXsQx0)) 


From R, is{pairK1s0(1sQ{1x0))). 
Let (sl, w) = rplaca(sOXx0, yO). 
Let <Isl, dw) = rplaca(!sOX1x0, Ly0). 
Then sl o Isl and we lw, 
By the definition of rplaca, 
sl(z) = sQ{(z) for z # x0 = w. 
By the definition. of A rplaca, . . 
{sl(1z) = lsQXLz) for 1z = lw and site) = 1s0(4c) foi tc * Js0(Lw) © oy) 
R holds in sO, 1s0, and. fromthe third clause.of Ry 
2 42 & 1 XO => IsK1z) # Ls0X(1x0). 
_ So dst(si(42)) = 480(1s012)) for bz. 4% #.x0. 
So R holds for x # x0. 
The first clause of R holds for x = x0. = w since> isiruliXsi(w)). 
From the definition of rplaca, w = x0. 
From the definition of trptaca, 1si(1w),#.4s0(4x0), 
and ‘tsi(Iz) = 1sO(iz) for dz # Iw. 
So the third clause of R in st, Jsi follows. from R in sO, Js0. 
From the definition of rplaca, si(w) = ¢t i r: eee ue 
Suppose x = x0 = w. 
Then from the third clause of R, 
x + Lx => Isi(tx) = {sI(Lw), and dsi(tsl(1x)).» Lsk{tsi(Lw)). 
’ From the definition of Irplaca, is[pairXtsi(1si$w))) and 
dsi{isi(Lw)) =. Ly0, r: LsO(1sQ{Lx0)). 1), 
We have y0 + Ly0, and since R holds in sO, 150, 
SO(x0).r + 480(1sO(1x0))- r. 
So the second clause of R holds in sl, isl. 
So R holds. 
Both rplaca and vplaca terminate in the normal condition for this case. 


Case 5.2: is{rullKsQx0)) 


-t%- 
Let rptaca(sOXx0, yO) = sl and Irplaca(4sOX1x0, ty) = Est. 
By the definitions of rplaca and: Irplaca, sO = sl and 4s0 = Isl, so R holds. 
Both esas and alow terminate in the to-car "tonditton for this case. 
Case 6: rplacd 
Similar to Case 5, proof left to reader. 
Case 7: eq 
Let sO #10, x0 + 1x0, and yO # !y0. 
Let eq(s0Xx0, yO) = <st, b) and Jeq(tsOX!x0, 1y0) « "sl, UB). 
By the definition of eq, si = sO and b = (x0 = y0). 
By the definition of leq, Ist = 180 and Jb = (4sQ{x0) = dsQXy0)). 
Since R holds in sO, x0 # 1x0, and yO # Ly0, (x0 = = yO) =  (ts0{ x0) = = $s0(Ly0)). 
So b = Jb, and R holds. 
Both eq and leq terminate in the normal condition. ' 


So list and Jlist are behaviorally equivalent. 


The mutable list ee was e chosen to ihustrate several issues arising from the 
sharing of ajutable data ree Since ¥ we have made a ‘brie distinction betiveer the identity of 
a token and its state, there is no notational difficutty ih stating that one object is a 
siticonnoadn of the states of several other objects (le, that the first object is shared by the 
latter objects). Note the use of the correspondence relation: # in the conclusion of the second 
' clause of the simulation relation R, to indicate that the identities of the components of a 
non-null list must correspond in the two models. | 

The example illustrates a case where there may be many distinct representations for 
the same mutable object. Every time a rplaca or rplacd operation 18 performed on a list, a new 
representation object for that list is created in the implementation. Despite the multiple 
representations, the externally observable behavior of mutable lists is correctly realized a the 


implementation, so that the non-uniqueness of the representation used by the implementation is 
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not externally observable. Whenever the state of a list is modified by a rplaca or rplacd 
operation, the change is reflected in the states of all of the representations for the abstract list 
that was modified, and not just in the particular representation that is returned as the result. 
This is accomplished by introducing an extra level of indirection: the state of a list in the 
implementation model is a cell containing the abstract state of the list. In our notation, if so ts 
are two corresponding states and if x # x are two corresponding lists, then the abstract state 
s(x) corresponds to the concrete state !s(1s(!x)), where !s(1x) denotes the identity of the shared 
cell. The cell is shared by all of the representations of the same abstract list, and all of the 
relevant state information is contained in this cell, so that any state changes are automatically 
reflected in all “copies” of the list object. The eq operation computes the identity relation on 
abstract lists, rather than the identity relation of the implementation model, which is not 
externally observable. The identity relation on abstract lists is described by the third clause of 
the simulation relation R. Note that the implementation depends critically on the fact that the 
data state of a token representing a list (the identity of the shared cell) never changes, although 
the data state of the data state of the token (the contents of the cell) may change. It is easy to 
check that this property is maintained, since none of the Jlist operations applies a stateSupdate 
operation directly to a token representing a list. 

The interesting part of the proof is case 5.1, where the normal termination of the state 
changing rplaca operation is treated. Note the use of the third clause of the simulation relation 
R to implicitly describe the set of representation objects affected by the operation. 
Implementation objects other than those passed as arguments can be affected by a rplaca 
operation, due to the shared mutable cell in the state of a list in the implementation model. In 


the argument to establish that the rplaca operation does not damage the simulation relation for 
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objects other than those apts as arguments, the relation caine by the. third eee of a is used 
to distinguish between the : set of objec that is | supposed tobe affected b by the operation, from 
those objects that are not supped to be affected. hs is ps ‘i acts ve cxabih that allt 


3 fat “fa nes | reste ares ee ia 


the objects whose states are 1 Spas fobs affected t by the Operation reflect he ue change a: as it eg 
to show that the objects that are ‘not supposed tobe afeced rea their r previous properties, 

* While it may be difficult to detive a description of Hee set of of objects that | & supposed 
to be affected by a “given operation irivie an implement of of aaa arbitrary motable data 
abstraction, it is ‘important to make this set expe, because oo seman from ) hidden 

tHe at haniging 2: AMiye Tora: ae 
interactions due to uriintended ilaring relations are ver aca - ison! sown, The CeSERer 
should therefore ae ‘explicit | and careful attention to the characterization of fhe st ais of ca. 
objects that should ‘be affected m1 an s cperition n during the deg oe the implementation The 
intended restrictions on the sharing lanai should be be written "down a pan 34 the design, 


page 


process, for later reference and for possible use in proofs This segeton is analogous to >the 


Fa P| 
suggested practice ‘of developing loops together with the ‘sincianed ‘oop invariants. ‘The 
suggestion is: motivated by the fact that the 3 equa intoraticn must be Inormaly considered 
by the designer anyway, and that it is easier to formalize a 2 familiar but informal irerion than ol 


is to derive the required eos from an untamilar implementation 


Hae ft- 5 
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6. Conclusions 


In this chapter we review the concepts central to this work, present a comparison of 


the algebraic and abstract model specifications, and suggest some directions for future research. 
6.1 Central Concepts 


We have been concerned with treating potentially shared mutable data. This 
orientation has lead us to adopt an object oriented viewpoint, and to define the correctness of 
an implementation of a data abstraction in terms of the behavioral equivalence of the 
implementation and the standard model. To prove the correctness of an implementation, we 
have found it necessary to replace the representation function introduced by Hoare [18] with the 
simulation relation. | We have also found that a form of computation induction is an 


appropriate method for proving properties of mutable data abstractions. 
6.1.1 Data Objects 


In this work we have adopted an object oriented viewpoint, rather than the more 
conventional variable oriented view. This die was motivated by our desire to treat shared 
mutable data. If there is no sharing of data, then a change in the state of a data object can 
affect at most one variable, and the change can be modeled as the assignment of a new 
immutable value to the affected variable. If data can be shared, then a change in the state of a 
mutable data object can affect arbitrarily many variables, so that the simplicity of the variable 
oriented viewpoint breaks down. 


In our approach, states are associated with data objects as well as with variables. A 
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mutable data object is modeled as a featureless token, which ie to identify the object. The 
value of a variable is a data object (or, token), The value. of a variable is affected by. 
aisignment Statements; The system state function maps each token inta its current data. state. 
For most mutable data abstractions all of the interesting properties of a mutable one ones 
other than its identity are subject to change, and are represented by the es sate associated 
. with the object by the current system state function. The state of a data object. of a given type 
can be affected by the primitive operations of the type. 

By introducing an extra level of indirection in our model, we achieve. localized. 
descriptions of operations that modify potentially Shared. data. _1f two, variables share the same 
data object, then they denote the same token, and any change in the data state.of that-token will 
be reflected _ both variables. After such a state transition, both variabjes retain their. original. 


values, since the identity of the shared data object is not changed, byt. the. properties. of the 


Shared object are different in the new state. 
6.1.2 Behavioral Equivalence 


The concep of behavioral equivalence of models is central to this. work, . Two, models ; 
are Sigil i blabla if bia | computation results, in Abe. seme termination condition. in - 
both models, and if any computation — with a boolean rewh. yields the same value in. both. 
models. This formal characterization of ‘the externally. observable behaviot of a mode]..is.. 
intuitively satisfying, since it says that two models are behaviorally equivalent if shey have the 
dine externally citibe properties. The characterization is atso useful because it allows us to. 
compare models with quite different internal structures. We have to examine. only the.names of 


termination conditions and boolean values to apply our definition of behavioral equivalence. 
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The representation of the objects of all other types is not explicitly mentioned, and can be 
different in the two models to be compared. System state functions are never explicitly 
compared, and it does not matter whether a model has a phylum of system states or not. It is 
quite possible for a state machine model (with system states) to be behaviorally equivalent to an 
exception algebra model (without system states). 

An implementation of a data abstraction is correct if and only if it is behaviorally 
equivalent to the standard model of the abstraction. We feel that this definition of correctness 
with respect to an abstract model specification is the right one to use, because it reduces to the 
classical one (existence of a homomorphism) for the case where both the standard model and 
the implementation model are static (see theorems.4 and 7), and because it applies also to 


dynamic models, whereas the classical criterion does not. 
6.1.3 Simulation Relations 


We have developed a method based on simulation relations for proving the 
behavioral equivalence of two models. The method can be used to prove the correctness of an 
implementation of a data abstraction with respect to an abstract model specification. The 
method is applicable to all models satisfying the assumptions set down at the beginning of this 
work, but it is most useful in the case where bath models are dynamic. Simpler methods based 
on correspondence functions and homomorphisms are available for the cases where one or both 
models are static, as described in Chapter 5. Simulation relations and correspondence functions 
were introduced because it was found that homomorphisms do not suffice for dynamic models. 

A simulation relation describes the relation that must hold between the representations 


and data states of corresponding objects in the implementation and standard models in order 
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for the externally observable behavior of the objects tb be the same. To show that two models 
are behaviorally equivatent, a simulation relation is explicitly constructed, and it is established 
that the:simulation retation holds fof alt reachable states by induction over all computation 
sequences. To establish: ‘behavidral equivalence, the “simulation ‘relation must imply that 
corresponding operations on corresponding objects résult in the same termination conditions 
and boolean values. The simulation retation miust also be strong enough to establish all of the 
properties of the inputs that the operations depend on, so that the indietben ‘will go through. 

Simulation ‘relations are defiried in termié of the correspondence relation «, which 
retates the identities of corresponding data objects in the two models. « is defined in terms of 
the computation sequence, by‘ saying that the resuRs of corresponding steps of the computation 
in the two models are related by +. Since the tokens of a dyiiahlic todel are anonymous, ‘and 
since operations that create new data objects result in tokens unrelated to previously known 
tokens, the only generally applicable method for establishing the correspondence is to appeal to 
the history of the computation. A simulation relation has ‘the same purpose as a 
homomorphism, but it cannot be defined as a function in the dynamic case because of the 
dependence on: the history: of the conmputation: In the stati¢’ case’ a simulation relation would 
require that objects related by are homomorphic images, but sincé there is no need: to separate 
the identity of an object from its properties in the static case, the horiomorphism cafy be used in. 


the proof directly, without intreducing: the « relation. 
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6.1.4 Proving Theorems about Data Abstractions 


In the main body of this work we have concentrated on proving the correctness of an 
implementation of a data abstraction with respect to a standard model specification. This is 
only half of the process required to verify programs that use data abstractions. The other half 
of the process involves proving that the invocations of the operations of a data abstraction in a 
program written using the abstraction have the specified effect. 

The intended behavior of a program is typically described by giving assertions 
expressing the relations that must hold between the data objects manipulated by the program at 
various points in its execution. For programs that use data abstractions, the assertions will be 
written in terms of the primitive operations of the abstraction. For dynamic abstractions, the 
system state must be explicitly included in the assertions, so that the operations can be treated as 
functions, and used without regard for the context in which they appear (ie., there are no side 
effects in the assertion language). 

The problem of showing that a program satisfies its assertions can be reduced to the 
problem of proving theorems about the data abstractions it uses, by using an axiomatic 
definition of the controt constructs of the programming language to eliminate the program texts 
from the correctness requirements. The theorems derived from the annotated program texts, 
which must be proved in order to establish its correctness, are called verification conditions. 
The process of deriving the verification conditions from an annotated program text has been 
extensively treated in the fiterature on program verification for the case where the data 
abstractions used by the program are well understood domains such as the integers. The 


process is not significantly affected by the introduction of static user defined data abstractions. 
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The introduction of dynamic abstractions raises the problem of introducing solic wannes for 
the antermediate system states, wre are implicit in. the program text but which are required in 
the assertions. This Process . wil ieee a flow analysis of the program.. Previous work on 
automatic verification of programs operating. on routable data {5I, 32) has not explicitly 
aniroducsd States into assertions, aveining this issue. While we. have, not investigated. the - 
aibienk s in detail, we foresee no essential difficulty, in Producing, verification | conditions for 
Programs that use mutable data abstractions. 

‘The -brociem of proving the. Verification conditions based on. an. abstract model 
specification presents no methodological problems, although just about any interesting data 
domain has theorems which are hard to prove. It is sufficient to prove, the interpretations of 
the verification conditions in the standard models of the data abstractions used by the program, 
nee behavioral equivalence guarantees that all of the ground. terms . composed . from. the: 
Snes Operations of the abstraction will have the ie truth values: in, Poth the standard. 
modet and any behaviorally equivalent implementation model, Pines. quantifiers can be 
retin ‘ range eve only the computable object of. _& data abstraction, behavioral . 


equivalence implies that any assertion will have the same truth valyes in both models. 
6.1.6 Computation Induction 


In doing the proofs of correctness of ‘implementation, in Chapter 5, we have. used a 
form of computation induction to establish that the simulation relation, holds for all (reachable) - 
objects and states of an abstraction This technique is useful for proving properties of dynamic 
data abstractions, and performs the same function as the generator induction Fule for.static data 


abstractions. There are two essential autterevces between the two kinds of induction. 
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The generator induction rule requires us to show that all of the operations of a data 
abstraction preserve the property to be sel Teens , sider of the data abstraction d 
using the comptitation induction rule, we must>show>that the operations of any mutable 
abstraction. subordinate tod preserve the property, in‘addition to the operations of d- This is 
necessary because the operations: of. the matable: sobordinate types‘ can cause ‘state transitions 
‘that can affect the truth of an assertion.invalving objects of typed (see Chapter 5). 

The generator induction rule -requires us wallow thatthe objects returned by each 
operation satisfy the property. we are trying: serene The: computation ‘iiduction rule also 
requires us to. show that all of the. values resulting from eacly operation satisfy the pienerty ‘we 
are trying to. prove, including the new systerv: state: furiction that és aff implicit resuk of each 
operation of a state machine. Since the system state function ‘descfibes the current states of all 
of. the data objects. inthe system, we have te:shew that the: property we are trying to prove 
holds in the new: system state for alt data’ objects, and wot just forthe data objects that were 
passed as. arguments to the qperation or that were returned-as-results” This is necessary because: 
an. operation can cause state changes’ in objects that-were fet patsed-as arguments, but which 


are reachable:from the arguments: ~~ ee a oP SE EY 
6.2. Algebraic vs. Abstract Model Specifications 


In this section we point out some of the retations “between the ‘abstract model and the 


algebraic specification techniques, and present a critical comparison between’ the two techniques. 
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6.2.1 Relation of the Techniques. 

The algebraic and the abstract. model:techniques are both iconcerned::with specifying 
the behavior of a data abstraction, and hence both. ave: dealing with’: the ‘same class of 
mathematical structures, although :there. ave slight technical differences in’ the way in whith 
different researchers define.the class. There-are. several watt known results relating ‘an algebraic 
specification to the class of models satisfying the specification. 

One- of the main algebraic results relevant-to the algebraic specification technique {9} 
is a uniforms construction. of a.canonical. model for: any. axiomatization ‘consisting ‘of a set of 
equations, where the expressions on , both. sides -of. each: equation are composed from the 
operations of the data abstnaction.. Fhe model resuking: from this construction is:a quotient 
Structure, whose elements are equivalence classes. of expressions, where ‘two expressions aré 
equivalent if one is derivable:from the other fromy the axioms: itt finitely ‘many steps. This 
thearem establishes a connection. between the proof theory of an: algebsaic specification and ari. | 
algebraic model for the specified abstraction. Fhe ‘thesrem allows ws to view an algebraic 
specification as a prescription for constructing a standard model for the data abstraction that 4s 
specified, so that an algebraic specification can be considered either as an axiomatization or as 
the definition of a standard model. : _ - _ | | 

_ Another important algebraic resuk is that the. canonical. model constructed as 
described above is an initial algebra in the category. of.algebras satisfying ‘the axioms {9}, which 
means that there is a homomorphism from the initial algebra to any other algebra in the 
category. In view of sieoeen 7, and the existence of the homomorphisms guaranteed by the 


initiality property, all of the elements of the category are behaviorally equivatent to the initial 
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algebra. In view of theorem 4, if the initial algebra is reduced, then there is a homomorphism 
from the initial algebra to ak, other gle sehavioray equate to it, so that the whole 
category is an equivalence velags with ies to behavioral Sancti if we restrict ourselves 


to static absiractions and to axiomatizations that define a reduced canonical model, nen the set 
of all models sariefvitg the axioms is the same as s the set of al models behaviorally equivalent to 


Reet §& a : tSe 


the canonical inodel, and our definition of correctness glia witty those used in the axiomatic 


approaches 7, 10, 91 For the case sehen the ean at model | defined dy ihe axioms is not 


seduced there is a lack of agreement on the proper definition of ad set - implementation 


consistent with an algebraic specification li, 9, 22] 
6.2.2 Critical Comparison 


The criteria for evaluating speciation techniques given in 1 BH are: w formality, (2) 


constructibitity, (3) comprehensbity, (4) ‘minimal, Cc) “rang a appa, and 6) 
extensibility. 7 

- Both the algebraic chi and the availa model iechici as acted in this 
work are sufficiently formal, since both techniques h have beet n given n mathematical definitions 


Both sechiiaues result in ‘minimal specications tt has often been (incorrectly said 


that abstract model specifications. are not ‘minimal “because the model may have srreex ane 


RIMES y cece ag” dae BYERS 


characteristics. As our definition of correctness iNustrates, only Shae properties of a peer that 
are excermally observable in terms of the sea aated of the abstraction are creevaal, and those 
ssiopentiCs must be defined bya any complete sprtietion. Ne Neither abstract mode! specifications 
nor “algebraic <peciieation constrain either the represent sear orth the algorithms that 


may be used by an ‘implementation, as ion as the externally observable behavior of ne 
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abstraction is realized. 
From a less formal — of view, it could be argued that the aber i sbaeeilaeey is 


not Xt directly observable in terms of the operation available to the user o she absracion: and 


ae ae 2 


that this introduces the burden of Keeping Hack of which cor are Lipid observable and 


wt 


which details are not, The axiomatic © approach has  anapes lt respect to ms criterion, 
| since there is no 2 explicit mention of the representation. Ae hat be nen shown 62) that there are 
abstractions that cannot be axiomatized without introducing suxiiary none Since the 
auxiliary functions also compute se alas that are not Srey observable: in terms mt the 
operations, axiomatic Specifications can also aera details that ae not appest: in an 
implementation. ae 

Another argument that ay been used to suggest that aperadt Lact Speciation’ are 
not minimal i is that the abstract representation | tends to sige an _ Implementation thts. is 
possible, but concern with issues of time. and space efficiency often requires, that | the 
representation used in an IMP IE ENtalion differ Heilkantty from ae ‘epresentation used in 
the standard model, which is usa the Plate structure that will alias the desired 
a The abstract representation is often defined in terms of amaifeerat ical structures not 
se supported by the host progenies feoguge so at in mime) cases it is $ not t possible to. 
use the 1 specification structure in the implementation. 

At the time of this wr hing. the abstract mode technique has a | Clear advanlage with 
respect te to range of applicability over the algebraic spectation echnigue, since it cals Abbie 
mutable data: while the algebra tcng does ot, We € expect ans advantage to ie a 
temporary « one, “which will disappear as further research extends anon specications tg 


apply to this donssin ale, 
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We have found abstract model specifications significantly easier to construct and to 
understand than algebraic specifications, This is a subjective impression based on our own 
experierice and we iigve the reader 2 try both techniques and to of his or her own opinion. 
Necture that part of the reason for our Wr experience i that, the ‘set of data objects is 
eplenlys described by an abstract model speciation, while it is b hopacly defined by the 


interaction of a potential er number of axioms in the algebra technique? The esun is 


eg: ens 


that the opeiations can often be understood and defined one at a time and based on fairly local 


considerations when using the abstract model technique, whereas the interactions between a 


% : “iE me FB 


number of operations must be considered in the algebraic approach, requiring a more global 
analysis. 
We have found that apatract model speciation are € significantly saner to masity 


than algebraic specifications: especialy. | in the case hers the meaning. of one ¢ operation is 


changed but the mearine of the abstract | representation is not changed, Becaute only the 


operation that is changed need be considered: Ina an m algebraic 5 roel id Me axiom n that 


mentions the Operation that was changed. must Lag reexamined, aed usually each operation is 
mentioned in more than one axiom. The enon of oe the espeiication of an abstraction 


by saa a new operation is roughly the same as that required t to Getine: 3 an N- operation in the 


iit i 


initial design, and again we have found that the A aie is easier abe. the abstract model 


ry at 


technique 


An algebrate specification can also be v viewed as ve definition of an abstract model, 


Airey es 


whose representation is the word aco: baker all of the expression that can be 
constructed from the names of the prt imitive e operations. ad abe ractions whose operations 2 are 


relatively ¢ easy to define ising this fepieibntation (ie, syntax trees), the algebraic specifications 


7 x 
ae sae 
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are relatively simple, while for other abstractions the operations may y be e quite awkward to serine 


using this represeniation, ‘and an + abstract model using a representation sgebra amin a 


significantly different structure. may be much singer | than the corresponding agora 
specification. From ‘this point of view, the abstrac model technique is easier to use simply 


because it offers : a wider choice of representation structures to start from. ‘Bye using the fixpoint 


Rolas 


construction to define a ‘representation d domain of sax trees, it is abway posible to define an 


fepena tye? gi Pad 


abstract model with, essentia ity the same structure as say given agebra definition 
Another criterion for judging a specttaton ecnique 5 the relative c aitficuky « of 
checking whether a “given. ecaliestion: is wel tceaiad If we are interested in using 


eee in the design sate it is isi ca for the Lagi of cri ania th ne specications 
to point out inconsistencies in the design, or at ical! to jake them easier to find, We would Lage 
seth fe FE : TRE! / : 


in formed specifications to ) be cay to rong. 


To check that an abstract model specitetion is ‘well formed it is Siena to ncheck 


erste 


that the ‘operations : are ‘well defined functions, and that the operations preserve the constraints: 


adopted when defining the model. For ‘each h operation, it is necessary to check that Ine: ¢ resus 
Ree aE CT a 

of the epeiatich satisfy the invariant relation apc by the restrictions section of f the 
it eee Le 4ehe Sy RSE F . 

specification. Iti is also necessary to > check that each operation will n yi equivalent results when 


of SLE UE Pere is ee 


applied to either of two data objects related by he sailvaketin's relation defined by the identity 
section of the pom ‘These asad are ed to ig uioaie ane they are 


generally not too difficult to prove rigorously. Iti is also o usally fairy nraghtorward to pence 


that the operations 2 are e defined for all inputs, and ‘resuk in mn unique vahies: ‘Tt is necessary to 


show that each invocation of 3 an ceaaiion that c can raise an exception will terminate in ine 


fist 


expected termination condition, and that each recursive definition Pa ‘each iota supretiian ee 
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Chapter 4) is well founded. Showing that a recursive function terminates is undecidable in the 
general case, but that seems to have little practical significance. In cases where something is 
wrong with the design, the designer will usually be unable to produce a function definition that 
even appears to be well formed. 

In the algebraic approach, there is no analog to the data invariant, and the 
equivalence is guaranteed to be consistent with the operations by construction (of the canonical 
model). If an attempt is made to define an operation that attempts to produce different value 
for expressions representing equivalent abstract objects, then the result will be an inconsistent 
axiomatization, where the multiple values are redefined to be equivalent. In such a case the 
Subordinate types of the canonical model often collapse into singleton sets. Incomplete 
definitions introduce extra data objects into the subordinate types, which are produced by 
expressions that cannot be reduced to bona fide elements of the subordinate types by the 
axiomatic definition. Rather than leading to an easily recognized failure, the algebraic 
technique will typically redefine the previously defined types in cases where the basic design is 
flawed. 

Determining whether a given axiomatization is complete and consistent is generally 
acknowledged to be a difficult problem in modern mathematics, and there does not seem to be 
any straightforward procedure for checking the well formedness of an axiomatization. There 
are mechanical procedures for checking whether an axiomatization is complete and consistent | 
that apply in restricted cases (the general problem is undecidable), but it is not clear whether 
these procedures can be used as practical aids in the design process. 

An advantage of algebraic specifications is that fairly powerful automatic theorem 


provers for algebraically defined data abstractions have been developed. This advantage is 
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probably also temporary, pending the development of good seth specif ic theorem Sievers roe 
the domains used to construct ‘standard model specifications. "For the dora of gide data 
abstractions, it is possible to define an abstract mode! using equational axioms, “by introducing 
an auxiliary operation that maps an object of the representation algebra | into ) the sbitract object 
it represents (cf. Hoare’s abstraction function, 08). “Such : an approach atiows ating advantage 
of known properties of the modeling domain, and also of existing, theorem provert for 
equational. axiomatizations: It’ suffers from the disadvantage of not being Anediatey 
applicable to mutable data abstractions. | 

in. eur opinion abstract model specifications are ‘clearly supertor to aigebraic 
specification’ for-the purpose of designing programs. The algebraic spectcatin technique has 
advantages for the purpose of: provinig the correctness of programs at the current time, since it 
has been more extensively developed, but we feel that a tong term advantage has not ‘been 


ce 


demonstrated. 
6.3 Directions for Future Research 


One imteresting question that has'been' raised but not resolved by the current work is 
whether or not abstract modet specifications are better than axiomatic specifications with eed, 
ta. program verification. Since the abstract representatiori ‘of each data type must be considered 
when using abstract model. specifications, and need not be considered when “using axiomatic. 
specifications, a naive analysis would indicate that proofs with respect ‘to abstract coda. 
specifications are more complicated’ than the corresponding ‘proofs with respect to axiomatic 
specifications, based on the sheer vohime of detait to be expected. However, in the oraots we 


have dane (mvanually), we have found that known propertie of the modeling domain can often 
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be carried over to the abstract domain, leading to short and simple arguments. This 
phenomenon may have an analog for mechanical theorem provers, since special purpose 
theorem provers designed for the particular modeling domains used in constructing abstract 
models may be more efficient and more powerful than a general purpose theorem prover that 
must work with arbitrary axiomatizations. 

If proofs of correctness are to be used for certifying software, then it is necessary to 
develop mechanical proof checking procedures, because proofs developed manually are at least 
as susceptible to errors as programs written by people. While a completely automated theorem 
proving facility would be nice to have, it looks likely that in a practical system the theorem 
prover will need human guidance, perhaps in the form of an informal outline of a proof, which 
the mechanical procedure tries to augment until it either discovers a formal proof or an error. 

Our experience with proofs in terms of abstract model specifications indicates that an 
intuitive understanding of the model derived from familiarity with the underlying modeling 
domain often acts as a valuable guide to discovering a successful proof strategy. For axiomatic 
specifications this intuition is often lacking, and the process of trying to construct a proof 
degenerates into fairly blind symbol manipulation and syntax directed searching more often 
than for abstract model specifications. If the theorem pfover must rely on human guidance, 
then the ease of finding intuitive insights can be an important consideration. We also 
conjecture that the extra structure provided by the abstract model is useful in constructing © 
heuristics to guide the search strategy of a completely automated theorem prover. 

In order to settle these questions, special purpose theorem provers oriented to the 
modeling domains used in abstract model specifications should be constructed and integrated 


into a program verification system. 
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Another question that is of ie is the pe exes of the framework meveloped here 
to incorporate nondeterminism and partial operations Both of these extensions require a 
refinement of the idea of behaviors! eulalence | 

af the pserations of a data abstraction can be 7 nondeerminic, hen a a COMpUNaniOn, no 
longer has a unique value, but rather a set of possible values iinlaas t equivalence « of the 
behavior of two models would ere that the set t of posible reat o a Lone be the 
same in both models. Since a more deterministic implementation of a sondeterminiee 
operation is aa correct if it alway exhibits one . the possible behaviors for the 
standard model, an approximation relation that t requires the set of i saoncigect results for the 
implementation | to be a subset of the set of posse resus for the sandard model is a “more 
a metric for the correctness of an 1 mplementation provided al the set of possible 
results is never empty. | 

Some abstractions have + potentiaty useful Phe sata pda ate inherently partial 
functions. One epi is the emma of Bs ahaa for a , Turing complete programming 
igi a with an hoperauon for evalating ss aaa In order to perce ® a sade! for such As 
structure, some sort of provision has to be made for ¢ cases fn which the operation do not 


5 


terminate. The meas of such an extension on the rest m of the theory should be investigated. 
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Appendix I - Assumptions and. Restrictions . 


1. Partial Operations - 


The he operation that ca can be defined in a na programing Janguage : are in general partial 
functions, since there may be circumstances under which they do not, terminate... We will require 
‘the operations of a data abstraction to be total, because we feel that it is bad Programming 
aig to design a abstractions with ith primitive operations that may f fail to terminate. Some recent 
work on specifying data abrasions with partial operations can be found in {27}. 
| Many cae abstractions have Pepe none. that make sense only f for some proper § subset 
of the pul domain » (ie. dividing by zero is not ba celine’) Jf an . operation is invoked with 
arguments that are outside its natural lilly of Celinitiey the operation: should terminate by 
ralsing 3 an exception, to indicat that someting vousal has happened. _ The reader should 
note that it is possible to transform a pares Partin! function, i into a computable. tatal. 
function that 1 raises an ‘exception ‘eal if the domain of definition 9 of the partial function. is a 
recursive om An Py inerpreter Ot sy Turing one language has | 3 domain gf definition that. 
is not recursive (otherwise the hating propkem: would be Geckdabe) demonstrating that there. 


pies ua 


are interesting functions that cannot oF nade: to D satiety our restriction. | .Partia} recursive 


Meri ” 


procedures that compute such functions can ot course be er inee in terms of the primitive 
operations ¢ of a  stttable oe 1 abstraction, but. we ee) net balow them to be included as primitive 


operations of the abstraction 


a 


2. Nondeterministic Operations _ 


We would like to distinguish between ° partially. - specified ‘operations and 
nondeterministic operations. A partially specified cecal is defined on ale some proper 
“subset of its input type, and presumably the designer does not care ae wha th the 3 operation Goes 4 it 
is presented with an ‘input outside of that ‘subset. We feel that c i bad design practise t to 
. produce’ specifications of this type, ‘because of the posibiity of sevdetscted: errors in shee use el 
the abstraction. The only case in which we ‘truly do not care what ; an n operation does « ona 
certain input is if we know that it will never be called with that inp. A well designed ¢ data 
abstraction should raise a an exception for ali inputs for which no nora respons is specified, so 
that attempts to use the operation outside of its domain of validity will not pass undetected 

Data abstractions with nondeterministic epertons ae potenti nerening,b mn are 
trot treated in the | main body of this work. ‘An operation an be described by an np gurpa 
refation R, which relates the inputs of an operation to the ral oupetv values for those hak ages 
For a deterministic operation, ‘such a relation is sete ‘valued, an is in fact 3 an ordinary 


ng iyi ud 


function. Some operations are most raturaly ‘described bis relation mvs are not single yale: 


wigs 6 : 


the programmer wants the operation to satisfy certain ener’ (et the relation mR). and does not 
care if there is a unique ‘result, or which valid result is + actually chosen, if there is more beds one 
valid choice. We do not recommend introducing. extra ‘constraints ts wth the sole purpose of 
restricting R to the point where it becomes a function, “Such constraints ‘complicate the: 
specification by introducing irrelevant details, and also may exchude 3 some e of the simplest ae 
most efficient implementations, which would be perfectly acceptable without the artificial 


constraints. 
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A non functional input-output relation R is consistent with a whole class of operations, 
some of which are deterministic, and some of which are not. The reader should note that it is 
quite possible to implement a data abstraction with. nondeterministic “Gpetations on a 
deterministic machine, because an abated data ord need not have a unique representation in 
the inipkerientatian: For example, conde’ the data mpi consisting. of the finite sets of 
natural numbers, together with the P usual set theoretic Sperauons.: and a choose operation. The 
choose operation cian element of a aie set if the set is nonempty, and raises an.exception 
otherwise. It is not specified wbich element of ihe set is to be chosen if there is more than one. 
Abstract sets are immutable, and two sets are equal if and only if they have the same elements. 
an an implementation, sets beds be represented as linked. lists, and the choose operation might 


return the first element i in the ue ouataal since ire are many, different representations for. 


the same set. with the elements stored in different orders, the choose operation appears..ta. be. 


“y a tee? 


nondeterministic when viewey as an salar on abstract sets. 


We know of | no work that has been done on _ Specifying. data abstractions with 
nondeterministic eperations, Some wok on ‘spectyng n nondeterministc Operations in terms of. 


relations is reported in C4, 


3.. Concurrency 


4 


Concurrent access to data objects by parallel processes is an interesting subject that is 


beyond the scope of this Thess : is ne. to. consider parallet processing: in the context of 
data abstractions {20, 16, o 38, 24) because nie Jpg to be i AuiabeliL te only if they 


operate on shared data. Even ‘hous a quite a bit of work nae soa done in this area, the 


issues involved in specifying the correctness of a data abstraction in the presence of concurrent 
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mutation of data objects are not yet well understood. 
4. Exceptions 


Since there is no generally accepted model of exception ‘and exception handling, w 


have chosen a ‘point of view that simplifies the interface presented nya an » operation, and which 
helps to separate the externally visible behavior of an n operation from the internal incieig that 
produce that behavior. 

We assume that an operation terminates whenever it rae an asian Thus an 


at 


operation may terminate in any one of a number of conditions one ¢ of which is normal a the 


etc. 5 


rest of which are exceptional. In general, the results of the qpecation' in Teach | condition wil ae 
different, arid must be speciied for alll posible  erminton condos In ina complete description 
of the operation. ee ee 
The alternative to our point of view is is to » allow an 9m exception 10 cause some ev events, and: 
then to continue performing the original operation at ‘the point oie it teft otf. This 
alternative is not attractive because the separation between the specifications of an operation, . 
and the details of its implementation breaks down. Given a a of aie that 
describes the results of the operation for the normal termination condjtion and ‘gives the” 
conditions under which each exception occurs, and ae a specification of an uencepion 
handler for each exception raised by the operation, we e still do mie enough information to 
predict the behavior of the operation i in 1 the context of the specited exception hander’: it is 
necessary to analyze the implementation of the operation with raped to the Specitications, of the 


exception handlers in order to determine ‘the effects of the eee Since different 


invocations of the operation can occur ‘in the contexts of different exception handlers, we cannot 
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treat an operation as a cose’ module he we scope, ths, , eH IOS nea of, exception handling. 


Exceptions are discussed further in bi Chores 2. 
5. Own Data 


We ssunne that the operations ofa data abstraction are functional. Pats means that 
an operation sii not have any internal state so that the resuks of an 1 operation depend only 
on 1 the sptormatton contained in the cata vote pase to dis operation as arguments (which 
ray include refer rence to other object). Data ope ~ themselves have States, so that we are. 
not excluding the possibility that an operation may return different results if it is invoked with 


the same arguments at two different times. This restriction is meant to prohibit type managers 


(ie. SIMULA classes, CLU clusters, ALPHARD forms, etc.) from keeping mutable own data, 


Yeas Ee 


which introduces a component of the state associated with the nes asa . whole, rather t than with 


the individual data objects. This issue is discussed further in Section 3.2. 
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Appendix II - Basic Type Definitions 
The definitions of the natural numbers and the integers are imported directly: from 
the underlying standard mathematics. The definition of the natural number eboraction is 
shown in Figure 24. As in the definition ‘of set in m Chapter 4, ‘the "standard notations hiss 
natural numbers and integers are used in the definitions of the operations to refer to the 
standard Operations of the underlying ‘mathematical domains, while the same notations are 
introduced as abbreviations for the operations of the exception atgebr, for use in the 


definitions of other modules. The only nonstandard feature of this definition of the wuatutat 


Figure 24. pcb de Numbers 
‘yee nat as NN- 


with constantin} — NN asn forn CN 


zero: —> NN as 0 
successor: NN — NN as 0(arg |) 
plus: ~ NN x NN-> NN as argi+ arg 2 
times: NN x NN -* NN as argi« arg 2 
less: NN x NN —> boolean as arg! < arg 2 
equal: NN x NN —> boolean as arg! = arg 2 
representation natural numbers N 
restrictions none 
identity natfequal 
operations constant[nX) = n 
zero{) = 0 


successor(x) = 0(x) 
plus(x, y)= x+y 
times(x, y) = x vy 
less(x, y= x <y 


end nat 
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numbers is the infinite parameterized family of constants. These operations are introduced ‘so 

that we can use the familiar decimal notation for natural numbers in our specification. language, 

rather than having to build up each number from zero using the successor function, which 

quickly eae Caer some: | | 

The peslalss of f the integers is shown f in Figure 25. Integers. also have an infinite 
supply of constant Cobeaiven’ Note the Savesan operations integer and nn, which serve to 
convert integers to natural numbers ated vite versa’ The ‘quotient and remainder operations 
have exception condition: in the cases where the’ standard mathematical definitions are 
undefined. « The gricetene operation rounds down ‘iriespedtive of the sign ‘of its arguments, in 
agreement with the usual mathematical definition, and in contrast to the way division works in. 
most programming languages (e.g., FORTRAN). 

The astute reader will have noticed that we have omitted the definitions of the 
operations >, #, <, and 2, even though we have used them fréely in the specification language. 
The astute reader will also be able to supply the standard definitions Tor these operations, and 
is advised to do so. | 

These ade are _inteniied for ween the Specinceion langilage. The corresponding 
types for a programming language should fry ‘be désigned differently, to include 
limitations on ‘the sizes of the numbers, sicsplien conditions ‘for cases in which those size 
limitations are exceeded, and additional operations for coanvetting ere of decimal digits into” 


numbers, and for printing out numbers. - 


Figure 25. Integers 


type int as I 
: ay, REIL ras Be Ts : os 
with constant[nk —> I] asn fornc Z 
integer: nat —> I Sis Age SAR RY 
minus: a | ; as - arg! 
plus: Ixlo] oo... 2: ag angle arg.2: 
difference: IxI->l . as argi+ arg 2 
times: IxIi-lI a aa.argi+arg.2 
quotient Ix 1 —> 1+ Gero. divide : ) 
remainder: Ix1—> 1 + Gero_divide.:). 
abs: al ae “as tarot 
nn: I > nat-+ (wrong_sign : de. : 
less: 1 x 1 —> boolean as ‘eulcee? 


equal: Ix] —bookan..... ss... as.arghe= arg2)-— 


representation _ integers Z 


restrictions none So Os: 
identity _  int¥equal 
operations constantinX) = 7 

integer(n) = nin Z. 

minus(x) = -x 


difference(x, y)= x= y 
times(x, y)= x oy 
quotient(x, y) = if y = 0 then (zero_divide : ) 

else q: dineaqe yer BOS te abdy)) 
remainder(x, y) = if y = Othen Gerogivide: 2 - 

else r: x= qoy ork 0S 1 <absy)} 
abs(x) = if x < Othen -x.ebex 
nn(x) = if x < 0 then <wrong_ ait else x in " 
less(x, yo xX < a0 
equakx, y) =x =y 
end int 


- 161 - 


Appendix III - Proofs 


An exception algebra differs from a heterogeneous algebra. as defined in by having 
a disjoint union structure for the ranges of the ¢ operations, where the dis Anion is indexed 
by termination conditions, and where the components of the. disjoint. union are, cartesian 
products of the phyla. In a heterdiginieor’ ry ‘the ange. of each ‘operation hast to: be some 
phylum of the algebra. The definitions of basic algebraic goncepts such: las beaasiesiay 
congruence relations, quotient structures, and homomorphisms have to ‘be adapted slightly to fit: 
into our framework. The required extensions are concerned mostly with termination conditions. 
For example, a congruence relation is an equivalence “relation that preserves all of the 
operations of an exception algebra, so that if Ccorrespooding arguments of an operation are- 
_ related by the congruence, then Aud plailueatiae conditions. af, the two invocations rst be 
identical, and corresponding return values must be related by the ‘components of the € congruence 
relation for the apprapriate pie: As in [1],,an equivalence relation an. an exception algebra is 


defined to be an indexed set of equivalence relations, one tor each phylum. 


Theorem 2: Every equivalence class of static models with respect to the behavioral equivalence ~ 


relation contains a reduced model. 


Proof: Let E be an aqiivatence class of models with . respect,to behavioral equivalence, «: 

and choose.M ¢ E: This: wilt Always be possible” 

since equivalence classes are nonempty by definition. : 
Let M' be the subalgebra of M containing only the reachable objects of the pings tye: 
and with the same subordinate types as M. 

M’ is closed with respect to the operations of M, since it contains all reachable data objects. 
Af’ is behaviorally equivalent to M 

since the value of any closed computation C in M' is the same as the value of C in M. 

Let M” = M'/=, where = is the external equivalence relation defined in Chapter 3. 
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M” is well defined because = is consistent with all of the operations by construction. 
Then M” is reduced and behaviorally equivalent to Mf. 

Every element of the principal type of M” is reachable, 

because any such element is equal to [x) for some x,in, the principal type of M’, 

and every stich x is reachable, by the construction of M’. 

Any two elements of the principal. type. of M” that are externally equivaient must be identical, 
by thie construction ofA” from M’. 

Hence M” is reduced. 

Mf” is behaviorally equivalent to M' because it Is a honioniorpike image of mM’, 

under the natural homomorphism A defined by Mx)» {x} if x. €&dand "ess ax otherwise, 
where ‘dis the principat type of MM’. 

Since behavioral equivalence is transitive, 

M? is:behaviorally equivatent to M, 

and the theorem is eoauihed) 

End of Proof 


Theorem 3: If two reduced models are behaviorally equivalent, then they:are:isomorphic. 


Proof: Let Mi-and Af2 be reduced and pete ricaly equivalent. 

Define the isomorphism f as follows. 

For every closed computation C, let f(vahie(C, Ml) « value(C, m2) 

By Lemma | below, whenever value(C, Ml) = value’, Mi). . 

them vatue(C, Af2) = valu’, 12), 

so that f is single valued, and hence a function. 

The inverse mapping is ébtained by eee Mi and m2 in the shore definition, 
and it is also single vahied, by the same > argument. Opin Bey aS 
So fist: h 

The operations of the algebra are preserved by construction, 

so the isomorphism is ciabished:. , 

End.of Proof = - 


~ Lemma I: Let MI and M2 be behaviorally equivalent exception seer models, let ¢ a8 Cc eee 
closed computations, and ‘let vatue(C, Ml) ‘= valuetC, Ma Then: rah mo ts eterna 


fet 
Sy 


equivalent to > valuelC’ M2). 
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Proof: let Ml and Af2 be behaviorally equivalent expan algebras, 

fet C and C’ be closed computations, 

let value(C, M1) = value(C’, M1), 

and let CO be an open computation. 

Then vatue(C0, value(C", M), M) = vatue(C"#COnM),: 

for any exception algebra M, 

where C"{ICO is the concatenation of the computations C” and COL? .. length(Co)h, 

and where the step indices of all of the argument specifications in CO 

have been increased by length(C”)-1. 

then —value(C0, vatue(C, M2), M2) = at igs 
value(CHCO,.Al2) = < aythe definition of coritatenation, 
value(C/ICO, M1) = since M1 and M2 are behaviorally equivalent 
value(C0, valuelG, Af), Mib= - ‘by the defitition of idoritatenation 
value(CO, value(C’, M1), Afl) = by assumption, 
value(C'HICO, Af) = bby the definition of concatenation, 
value(C’}ICO, A12) = since Ml and M2 are behaviorally*equivaient, 
vatue(C0, value(C’, Af12), A412) bby the definition of concatenation. 

So value(C, M2) is externally equivalent to value(C’, M2). 

End of Proof 


a 


Theorem 4: If M is behaviorally equivalent to M* ‘and’ M is reduced, then, there isa 


homomorphism from a subalgebra of M’ onto M. 


Proof: Let M” Be the subalgebra of M’ containing only the reachable 

objects of the principal type of M’, 

and with the same subordinate types as M’. 

The quotient of Af” with respect to the external equivalence relation is reduced, 
and behaviorally equivalent to M’ by Theorem 2, © 

and by transitivity of behavioral equivalence, it is also behaviorally ae. M. 
Then by Theorem 3, the quotient is isomorphic to M. 

The composition of the natural homomorphism, from.d6” to the quotient-and 
the isomorphism guaranteed by Theorem 3 is a homomorphism from M” to M, 
so the theorem is established. 

End of Proof 


Theorem 5: Every chain of algebras with respect to C has a least upper, bound. 
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Proof: Let A; : i ¢ 'N bea chain of algebras with respect to £. 


Then A = a A;, where A is defined as follows. . 
ic 


Va ¢ A.typenames [ A. phyla, = Pe yy 4" Phila 3 


VB c A. opnames [ Agen uu gy Ae neratnen  *: 


ASAE nae Aye, 


ier x se be any one of the following components: 
typenames, opnames, teryamas, arglengts, aretype. testength, rype: ‘or ae 


By Lemma 2 the operations and. Spe desxgon Senations areseltiined. 


A; © A for alli € WN, 


Kes SS U ee te . 


So A is an aoe bound for the chain Ay. 
If A; © B for alli c Nthen AC B, 
since 5; © S for all i ¢ sah dela : wis? 


So A is the least upper vevae? for the chaig, Ap 
End ‘of Proof 


Lemma 2: If f;: i N is a chain of functions with respect to ©, men SS : wt is a well 
: - era etechaih ge Sah pues gS OF eee 


ci 


defined function. 


Proof. Wohevete tne, Pe afi inch le ead. Di A 


Proof by contradiction. - 

Suppose / is not single valued. . a: 
Then for some x, (x, phe acting ef wherea b 
Since f = eg wit f 


pick n, m nk that (x, a) ¢ f, and G, b) C fy. 


Since f; isa chain, fy © fmax(n, m) 2° fm SSmax(n, my 
So (&,@) © frnax(n, m) and (x, 6) © fmaxn, m) where a # b ee ce hneies 
But f, is a single valued fimetion for ‘all 7  W, contradiction. 


So f must be single valued. 
End of Proof 


- 165 - 
Note that we are treating a function f as the. set taf. wash aia a hades ‘such that x € caves 4 


Theorem 6: The tuple ididloctaalion, is ‘continueus. with raiment c 


Proof: Let A; be a chain with respect to C. 

Let U denote the least upper bound with respect to &.:-: a 
( UA) xX Sy kK. x Sp = U (A,X Sy KB RO 
icn icNn - . 


from the definition of union and cross product. . 


The definition of each operation is a functional F from the phyla to operations on the phyla, 
with the property that the value of an operation on any input depends only on the input values, 
and not on the phylum ; asa whole. 

(The finite quantification in the definition of equal can be Sipe 

into an equivalent finite conjunction.) ; 

SoFWS, Xx) = F(S pe for any § 
F(S Xx) is andehaed ifo-xe S, 
So FU 5;Xx) =U F(S Xx). 


j Such that x ¢ 5p 


The definitions of the signature furicttons also have this proper ge: uF 0 ae 
So the tupte:transfermation: or algebras Cone: datos gcedce ee a 
Ene of Proof 


oad 


Theorem 7: Let M1 and M2 pe ee exception aige midis iia bpsaliad Signature and 
> endwhrs i! 


the same interpretations for: the ‘ubortinatape, ave ea pomeraphiun fa M1 to 
M2, such that A is the identity mapping on an of the * toro types, Then 4 Mi and M2 are 


behaviorally eaiivatent. 


Proof: For every finite closed computation C, we have to show that: 

A. C is feasible in Afl if and only if C is feasible in M2. 

B. value(C, M1) = vatue(C, M3) whenever C is feasible in Mase prot a boolean value. 
Let H(C) = ( feasible(C, 41) = feasible(C“M 2) )} & 

-(Clength(C) 2 1 & fcasibletC, AH) }:- > a(vatnetG; MA)):2 valueiti Me: 

Assuming that H(C’) holds for all C’ such that length(C’) < tenithiCh 

show that H(C) holds. 


Case t: length(C) = 0 
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H(C) is trivially true, since the antecedent of the tmptication is fatse. 
A. holds since the empty computation ts feasible in any model. 


B. holds since there are no: computations of length 0 prodiicing a boolean value. 
Case 2: length(C) > 0 


Let length(C) = n and let C’ = C{t.. n-I} Sich 
Then H(C’) since tength(C’) = n-1 < tength{C). . 


A. To show feasible(C, Mt) if and only if feasible(C, M2) 
| Case 2.1: C* is rrot feasible in Mi 


Then by the induction hypothesis H(C), C’ is not feasible in M2. 
Since C’ is a prefix of C, C is not feasible in Mi or M2. 
So A. holds for case 2.1. 


Case 2.2: C’ is feasible in M1. 


Then by the induction -hypothesis.C’ is feasibledp 62 . 
Therefore the termination canditiens of:the arguements match the regiments: 
for every step of C’ in both models. oe 
C is feasible in MI if and only if the termination conditions of the spain of Cin) 
match the requirements of step C{n] 
_ Each argument.xy is tre wale roc. oes cre FT es 
where length(C, ) 2 land where C, is a proper sre of C. 
> By the induction hypothesis Mvaltie(C;, M1) = 'vatielC,, M2). 
Then te(A(value(C;, M1) = = telvalue(C,. | M2), _ 
since homomorphisms preserve termination cortditions. 
Therefore the arguments will match the requirements for the interpretation of 
C in M2 whenever they will match for the interpretation of C in M2. 
So A. is established for case 2.2. 


B. Assume C is feasible in'’MI and tength{C) > t. 
Show A(value(C, M1) = vatue(C, M2). 


Each argument x; of the last operation of C is the result of some prefix C, of C, 
where I < lengthiC, )< tength(C). 

By the induction hypothesis, A(value(C,, M1) = valae(C,, 42). 

Since A is a homomorphism, A preserves: the Speeieet of MI and side 

So A(vahie(C, MD) = valuetC, 442). 


So H(C) for all computations C. 
If the principal type of M1 is boolean then MI = M2, 
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since there is a unique standard model for the boolean domain, 
and otherwise boolean is a subordinate type. 

In either case, Abootean is the identity mapping. 

So if a computation results in a boolean value, 

it must result in the same boolean value in MI and in M2. 

So MI and M2 are behaviorally equivatent. 


Then H(C) holds for all finite computations C. 
End of Proof 


Theorem 8: Let Ml be a state machine model and fet M2 be an exception algebra model with 
the same signature and the: same interpretations for the _ Subordinate types. Let ¢ be a 


correspondence function from MI to M2, such: that ¢ returns its second argument for all 


subordinate types. Then MI and M2are behavioral equivalent 


Proof: For every finite closed computation C, we ae to show that: 
A. C is feasible in M1 if and only if C is feasible in M2. 


B. vatue(C, Ml) = value(C, M2) whenever C is feasible in MI am produces a boolean value. 
Let state(C, A7) denote the final state produced by. | 
the interpretation of the closed computation C in the s state machine model M. 


Let H(C) = ( feasible(C, Ml) = feasible(C, MD) & 

( length(C) 2 1 & feasible(C, M1) ) => c(state(C, M1), value(C, MD): = . valuel(C, M2): 
Assuming that (C') hebds for all Cc such that Tengeh(C}) < length(C), . 

show that H(C) holds. 


Case I: length(C) « 0 

H(C) is trivially true, since the antecedent of the implication is false. 

A. holds since the empty computation is feasible in any model. 

B. holds since there are no computations of fengtl O producing a bootean value. 
Case 2: length(C) > 0 


Let length(C) = n and let C’ = Cf... n-i). 
Then H(C’) since length(C’) = n-i < length(C). 
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A. To show feasible(C, M1) if and only if feasible(C, M2) 
Case 2.1: C’ is not feasible in MI. oe ne . a 
Then by the induction hypothesis H(C).C 1s pat fensiblecin. M2. 4 
Since C’ is a prefix of C, C is not feasible im Mb ap M2}. 05060505. 
So A. holds for case 2.1. 
Case 2.2: C’ is feasible in M1. 


Then by the induction hypothesis C’ is feasible in M2. 


Therefore the termination conditions of the.argumentsmatch the requizements 


for every step of C’ in both models. 


C is feasible in M1 if.and gnly.if the,termination cenditions ofthe arguments of Cin} 


match the requirements of step Cin} 


Each argument x, is the valueof:C;, be fee ee Oo EN 


where length(C;) 2 | and where C; is a prefix of C. 

By the induction hypethesis tstate(,, MY; vatuelC,, M1) « valie(C,,"A42). 
Then te(d(state(C;, Mi), value(C,, Ml) = te(vahue(C,, M2)), 

since correspondence functions preserve termination conditions. 
Therefore the argunvdits' wilfmatch thé requ ‘for 

the interpretation of C in M2 

whenever they will match for the‘interprétation of ¢ én M2 
= = is Lepabushed Lick case od 


B. Assn C is feasible in 1 MI and 4 Nengthic) 2 24 
Show c(state(C, mi), Mabagiies MM - bee alia 


eer 


Each argument x, of the last seers of c is he re of some. pt o of C, 
where I < length(C,) < length(C). eek 

By the induction’ ‘Hypothesis, dstate(C;, an, “valuelGg, M1)» = hed HO 
Since C; is a prefix of C, “dstatelC;, M1), x;) = = c(state(C, M1), x,), 


by the monotonicity property of correspondence functions. 
Since ¢ is a correspondence function, c preserves the operations of Ml and M2. 
So e(state(C, M1), value(C, M1)) = aia Me 


ay 


poe certed he 


So H(C) for alt computations Gon, : 
By the hypothesis of the theorem,.¢.i is the iin eacongan sie beckananelin.” 
So if a computation results in‘a boolean value, 

it must result in the same boolean value in M1 and in M2. 

So Mi and M are behaviorally equivalent. 


Then H(C) holds for all finite computations C. 
End of Proof 


sod 
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Appendix IV - Syntax. - 


The syntax of an abstract model sapreltcation is given below in an extended form of 
bnf. [X] means that X is optional, Large pamabun ( ) are symbols of the meta language 
used for siciging terms. Small parentheses and square brackets zl T, and ob are terminal 
symbols denoting the respective characters themselves,. X* means,X can be. repeated. zero or 


more times. X* is the same as X X*(X may occur one or more times). 


<specification>::= <modute> | <type definition>— es 
<modules::= module <type définition>’ end module 


<type definition>::= type <type name> {parame ins} Labofeition 
[<requires>] 
<signature> 
<rep spec> 
<Ops> 
[<auxiliary signature>} - 
[<definitions>] 
end <type name> 


<parameter list>;:« [ <parameter-‘name> (., <parameter name> )* } 
<abbreviation>::= as <abbreviation body> 


<requires>::= requires <parameter type> (, <parameter type> )* 
<parameter type>::= <parameter name> : <type name>.[ such-that: <predicate> } 


<signatuse>:= with <fanction type>’ 

<auxiliary signature>::= internal <function type>* 

<function type>::= <function name> : [ <domain spec> ] —> [ <domain spec> ] <condition spec> 
<domain spec>::= <type name> ( x <type name> )* 

<condition spec>::= + ( <exception name> : [ <domain spec> ] ) 


e 


-fo- 
<rep spec>::= <domain equation»: [crestriction>] [<equivatente>] 
<domain equation>::= <domain name> = <domain expression> 
<domain expression>::= <domain name> | { <demain name>‘ } 
| tuple [ clabeled expression tist> J] 
| oneert{ <tabeted éxpréstion tist> J) 
| set <domain expression> } 
wed: <domdi expression> } 
clabeled expression list>:= <labeled expression> ( , <labeled expression> e. 
labeled expression>-= <dlabel> : <tomatn’ ckpessions 
<restriction>::= restrictions none | restrictions <identifier> such that <predicate> 
cequivalence>:= Identity <operition name>” 


<ops>::= operations <operation definition>* 
<definitions>::= definition <operation definition>’ __ 84 eee Pee oe 
<operation definition>:= <operation name> <argument. list> = = <operation body> [ <ipcals>:] 
<argument list>::= [ ( <identifier> ) ] ( <identifier>? ) - : . 
<operation body>::= <identifier>.| <aperation name>. <Seapeession list> cmet cr tite. aie 
| <identifier> : <predicate> bese 2 
| if <boolean expression> say hi guecnees 
then <operation body> : 
else <operation body> 
<expression list>::= () | ( <operation body> (, copetatiop-ondye Ht) 
<locals>::= where ( <variable> = <operation body> y 


The grammar shown’ above specifies onty the COMER: nee dt sghh of: ie: language. 
There are a number of additional constraints aa must be 36 met for a well formed specification 
For example, the number’ of ‘ryan expressions to an i coocrarie ees nue body must 
be the same as the number of type names in the domain specification of ‘the’ Operation in the 


Signature. 
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